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PREFACE 


0.1 MANUAL OBJECTIVES AND READER ASSUMPTIONS 


The IAS System Generation Guide provides the user with information 
needed to perform an IAS System Generation. It assumes a knowledge of 
system information provided in the IAS System Release Notes and an 
understanding of the material covered in the IAS System Management 
Guide. 


0.2 DOCUMENT STRUCTURE 


The Manual consists of the following chapters and appendixes: 


Chapter 1 Introduction to System Generation 

Chapter Z Preparing for Stage l 

Chapter 3 System Directives 

Chapter 4 Timesharing Executive Parameters 

Chapter 5 Transferring the Distributed System 

Chapter 6 Stage 1] Procedures 

Chapter 7 Stage 2 Procedures 

Appendix A System Generation Files 

Appendix B Device Characteristics Words 

Appendix C System Generation for Terminals on DHll 
or DJll Lines 

Appendix D MCR Commands 

Appendix E Error Messages 


0.3 ASSOCIATED DOCUMENTS 
Refer to the TAS Documentation Directory, Order Number 


DEC-11-OIDDA-A-D, fora description of all the associated IAS documents 
and their readerships. 


vil 


CHAPTER 1 


INTRODUCTION TO SYSTEM GENERATION 


1.1 OVERVIEW OF SYSTEM GENERATION 


System generation is the process of building a system tailored both to 
an installation’s hardware configuration and its software 
requirements. The IAS system distributed to the user on magnetic tape 
.is an operational single user system which is then modified according 
to the installation’s needs. 


IAS contains a System generation program that accepts user-provided 
definitions of the system to be built. The program executes in two 
Stages to create an IAS system based on the definitions provided. The 
first stage defines the hardware configuration, and memory allocation. 
The second stage defines the Timesharing Executive, which controls all 
batch and interactive processing. 


System generation is normally performed for one of the following 
reasons: 


1. To generate IAS for the first time 
2. To revise IAS when the hardware configuration has changed 
3. TO revise IAS in order to improve performance 


This manual provides sufficient information to generate a system for 
any of the above reasons. Chapter 1 describes system generation in 
general. Chapter 2 discusses in more detail both phases of System 
generation and system bootstrapping. Chapters 3 and 4 describe in 
detail the directives and parameters that the user must’ specify. 
Directions for generating the IAS system distributed on magnetic tape 
are contained in Chapter 5. Chapters 6 and 7 contain step-by-step 
instructions for modifying the distributed or an existing system. 


1.2 THE DISTRIBUTION SYSTEM 


Digital distributes IAS on magnetic tape. Users must then transfer 
the distributed IAS system from the tape onto the system disk. 
Chapter 5 provides step-by-step instructions on how to effect the 
transfer. 
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Once IAS has been transferred to the system disk, the installation has 
a workable single-user system. This system is then used to generate 
IAS according to local requirements. The user specifies the local 
requirements by editing several files that are read by the system 
generation programs. The following two sections describe the files to 
be edited. 


1.3 STAGE 1 

Stage 1 of system generation defines the installation’s hardware 
configuration and memory allocation and then installs all the tasks 
needed to run a complete IAS system. The target device is a disk 
(possibly the current system disk) which contains the necessary files 
(see Chapter 3, section 3.2.3.5). This procedure consists of two 
phases: 

1. Phase 1 defines the hardware and the allocation of memory 


2. Phase 2 installs the necessary system tasks. 


1.3.1 Phase 1 


There are two files relating to Phase 1 of the Stage 1 system 
generation that must be considered: 


- A MACRO source file containing terminal handler parameters 


- An indirect command file containing system generation 
directives 


An indirect command file is a Sequential file containing a list of 


commands. To execute the sequence, the user issues an "at" sign (@) 
followed by the file name instead of the first command in the 
sequence. The system then retrieves the indirect file and executes 


the commands contained therein. See the IAS User’s Guide for a more 
detailed explanation of indirect files. 


1.3.1.1 Terminal Handler Parameters -—- The MACRO source file contains 
information required to build the terminal handler. It specifies the 
number of terminals and the hardware interfaces used to attach the 
terminals to the system. The user must edit the parameters file to 
reflect the local hardware configuration. 
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1.3.1.2 System Generation Directives - The system generation 
directives contained in the indirect command file fall into six 
categories: 


1. The TARGET directive which defines the target system device 
2. The PDP-11 directive which defines the computer to be used 
3. The EXEC, SCOM and PAR directives which partition memory 


4. The DEV directives which define the system peripherals and 
pseudo devices 


5. The DPAR, CKPNT and SY directives which supply system default 
information 


6. The INS directives which install tasks needed for phase 2. 


At Stage 1 of system generation the user must supply these directives 
to define the installtion’s hardware configuration and _ software 
requirements. The real-time and timesharing activities to be run on 
the computer determine how the system manager decides to allocate 
memory. See the IAS System Management Guide for a discussion of 
memory allocation. 


The user either edits the existing command file containing the 
directives or creates a new file. The directives are then issued by a 
call to the indirect command file. The user also has the option of 
typing the directives individually at a terminal. See Chapter 3 for a 
detailed description of each directive. 


1.3.1.3 The Results of Phase 1 - When the two files described above 
accurately reflect the installation’s requirements, the user can 
perform phase 1. USing the terminal handler parameters and system 
generation directives, phase 1 produces a software system capable of 
driving all the installation’s peripherals and of controlling its 


memory. See Chapter 6 for detailed instructions on performing phase 
1. 
1.3.2 Phase 2 


Phase 2, a task called SGN2, is installed automatically during phase 
1. When the system established by phase 1 is activated (see Chapter 6, 
section 6.2), phase 2 begins to run and performs the _ following 
actions: 


1. It loads the terminal handler 
2. It issues a MOUNT command for the system device (SY) 
3. It opens the file SY¥:[11,17]SYSBLD.CMD and, if the open is 


successful, begins to process the file and print it at _ the 
console. 
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The file SyY:[11,17]SYSBLD.CMD installs all the tasks needed _ to 
complete the IAS system, including the current version of the 
Timesharing Executive. Appendix A lists the contents of the 
distributed version of S¥:[11,17]SYSBLD.CMD. The user should make any 
necessary changes to the file before initiating phase 2. 


The phase 2 directive *DELAY is inserted to cause a l-second delay in 
the processing of commands contained in SY:[11,17]SYSBLD.CMD. Some 
command sequences may fail if a delay is not specified. See Chapter 
3, Section 3.2.6. 


1.4 STAGE 2: GENERATING THE TIMESHARING EXECUTIVE 


Phase 2 of Stage 1 system generation installs the current version of 
the Timesharing Executive. To perform Stage 2, the revision of the 
Timesharing Executive, the user must first edit the file 
[311,197]SGDATA.MAC. This file contains the IAS interactive and batch 
parameters used to create two libraries which the system requires to 
control timesharing activities. These parameters are described in 
detail in Chapter 4. 


When each parameter has been set to the required value the user. then 
assembles and builds two libraries. The libraries IASCOM and IASBUF 
are Shareable Global Areas (SGAsS) that contain data structures’ and 
common routines used by Timesharing Executive tasks. The libraries 
are built according to the parameters specified in 
[311,187] SGDATA.MAC. 


Once the libraries have been built, the user must relink all the tasks 
that use them. The next step is to remove the old libraries and tasks 
in order to install the new ones. The new versions of IASCOM and 
IASBUF are installed first, followed by the tasks. 


The user completes Stage 2 by dismounting the target disk and _ saving 
the system. A new Timesharing Executive has then been generated. 


A step-by-step description of performing Stage 2 is contained in 
Chapter 7. The procedure is greatly simplified by the use of indirect 
command files for assembling, linking, removing and installing tasks 
and libraries. 


CHAPTER 2 


PREPARING FOR STAGE 1 SYSTEM GENERATION 


This chapter contains information to help the uSer prepare for both 
phases of Stage 1 system generation, including a detailed description 
of IAS bootstrapping procedures. 


2.1 EDITING SYSTEM GENERATION FILES 


Several indirect command files for system generation are provided in 
IAS. These indirect files can be used to define the system in phase 1 
instead of typing directives in response to phase 1 requests. (Phase 
1 system directives are described in Chapter 3.) SYSBLD.CMD is always 
used to perform phase 2. If the user wishes to tailor the system to a 
particular installation, he can either edit the existing files or 


create new ones. See the IAS Editing Utilities Reference Manual for a 
description of the editor. 


All commands files are stored under UFD [11,17] on the system volume. 
Type the following commands to request the editor for the modification 
of existing generation files or the creation of new ones. 


MCR>SET /UIC=[1,1] 
MCR>EDI [11,17]command file 


2.2 POOL REQUIREMENTS OF SGNI1 


Phase 1 of system generation (SGN1) uses the dynamic pool for storage 
of input data and for communication with the version of install 
(..- INV) that it requests. SGNl returns nodes to the pool as soon as 
it has finished with them. If a fatal error occurs, it returns all 
nodes using its own internal accounting system. 


As a result, pool usage is guite dynamic. The important 
consideration, however, is the maximum uSage at any time. To compute 
the maximum pool usage consider the phase 1 command input while 
referring to Figure 2-1. 


EXECUTION OF SGN1 


TARGET 
PAR 
DEV 
INS 


Loop repeats 
once for 
each task 
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NODE USAGE 
1 node = 16 contiguous words. 


This graph does not include MCR buffers of nodes 
used by the file system. 


1 2 3 4 5 6 7 8 9 10 


1 node only if UIC and/or filename is specified 
1 per PAR 


1 per DEV 


1 per task 


Calculate system mapping 

Create target system image file 
Exec, null task, pool written out 
PUDs created and written out 

3 nodes picked for control of ...INV 


Return task description data 
Request ...INV 
..-INV creates an STD 


— eee ea rr eK eK 


All tasks installed in target system 
Return 1 ...INV control node 


Return all device information nodes ~ 1 per DEV 


Write alpha table 
Write STDs 
Return STDs -- 1 per task 


Create ATL entries 
Write partitions 
Return PAR data -- 1 per PAR 


Create bootstrap on virtual block 1 

Write SCOM to memory 

Close files 

Return all outstanding nodes -- 3 if SGN1 is successful 


mr “+—~_All fatal SGN1 errors enter here 


Figure 2-1 
SGN] Pool Usage 


PREPARING FOR STAGE 1 SYSTEM GENERATION 


2.3 PHASE 2 OF SYSTEM GENERATION 


Phase 2 of system generation is installed during phase 1. On bootstrap 
from a phase 1 target disk as described in Chapter 5, section 5.1, 
phase 2 is activated and proceeds as follows: 


1. Loads the terminal handler, 

2. Issues a MOUNT command for the system device (SY), 

3. Opens the file SY@:[{11,17]SYSBLD.CMD, and if the open is 
successful, begins to process the file and print it on the 


console. 


The file SYSBLD.CMD is provided in the IAS system. If the user wishes 
to modify it, he should do so before bootstrapping phase 2. 


SYSBLD.CMD can contain the phase 2 directive, *DELAY, described in 
Chapter 3, section 3.2.6, and any MCR request except SAVE or BOOT. 


A task must be installed before it can be used. The task can be 
installed either during phase 2 of system generation or during phase l 
by means of the INS directive. If the task refers to a shared region, 
the referenced region must be installed before the task is installed. 
(Note that shareable gobal areas or tasks which refer to shareable 


global areas can not be installed during phase 1. They must be 
installed during phase 2.) 


When phase 2 iS complete, it prints the following message on the 
console. 
END OF SYSTEM GENERATION PHASE 2 


At this point, perform the steps in Chapter 6, Section 6.2 starting 
with step 4. This process properly saves the system for continued uSe. 


2.4 IAS BOOTSTRAPPING 


The PDP-11 family of computers is supplied with a hardware 


bootstrapping program in read only memory. The function of this 
program is to read one block (physical block @) of a specified device 
into main memory starting at real location zero. On successful 


completion of the read, the processor jumps to real location zero with 
memory management disabled and starts to execute the contents. 


Under IAS, block zero of the booted device must contain a program to 
read in the whole operating system and user-defined partitions, enable 
memory management, and start the Executive. 


During the generation and subsequent management of an IAS system, the 
Operations related to the bootstrap go through several phases. 
‘Although these operations are relatively transparent to the user, the 
system manager should be aware of the actions taken and their 
implications. The operations can be divided into the following four 
categories: 
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1. Phase 1 of system generation 
2. Phase 2 of system generation 
3. Saving the generated system 


4. Subsequent bootstrapping and saving of a stable system 


2.4.1 System Generation Phase 1 (SGN1 


The purpose of the first phase of system generation is to create a 
file, IAS.SAV, for example, on a target disk. This file is a bootable 
IAS system image configured for the target hardware; that is, the 
contents of IAS.SAV on completion of phase 1 are independent of the 
hardware configuration on which it was created. The only 
bootstrap-related function performed by SGN1 is to include the 
bootstrap at the beginning of the IAS image file. 


Due to differences among mass storage device controllers, the 
bootstraps for various devices differ in their control logic. 
Therefore, IAS provides a bootstrap program for each different device 
Supported as a system device. The bootstrap programs are named using 
the convention xxxxBOOT.TSK where xxxx is the commonly-used name for 
the device. At present, bootstraps are supplied for RK®@5, RP@3, and 
RP@4 disk devices. 


Using the SY directive and the related device specification, SGN1 
determines which bootstrap task is to be written into the beginning of 
the memory image file that it is creating. 


Before it writes this task into the image file, however, SGN1l must 
insert the following information into the program. 


1. The amount of memory to be filled. 
2. The disk address of the IAS.SAV file. 
3. The real base address of the Executive. 


4. The external page address of the disk controller as specified 
by the corresponding DEV directive. 


5. The kernel virtual address of the power recovery routine 
within the Executive. This routine is used to start the 
Executive as well as to recover from a power failure. 


The first four items are available to SGN1. The last (power recovery 
routine address) is obtained by building the appropriate bootstrap 
task with the Executive symbol table, EXEC.STB. SGN1, therefore, 
inserts items one through five above into the bootstrap task before 
writing it to the IAS.SAV file. 
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To insert the required information, SGN1l must have access to the 
symbol table of the bootstrap task. Consequently, SGN1 also reads 
xxxxBOOT.STB to determine the bootstrap program’s data locations. 
Since the bootstrap is linked with the EXEC.STB, SGN is able to locate 
all other symbols for the target Executive from the bootstrap task 
symbol file. 


During phase 1 of system generation, the user has the option of 
defining base addresses for the Executive, the system communication 
area, and partitions. If base addresses are not specified, SGNI1 
performs a memory allocation and places the Executive on the next 32 
word boundary after the bootstrap program. SGN] determines the length 
of each bootstrap from the corresponding .STB file. 


If the user specifies the base address, he must take care to leave 
sufficient space for the bootstrap program. The user can determine 
the bootstrap size by obtaining a task builder listing of the 
appropriate xxxxBOOT.STB. The following command is used. 


MCR>TKB ,LP@:=[11,17] xxxxBOOT.STB 


The difference between the global symbols .BO.BB (begin bootstrap) and 
-BO.ND (end bootstrap) rounded up to the next 32 word (19@ octal) 
boundary provides the lowest real address at which the Executive can 
be placed. 


It is important to note that IAS does not write block @ of the target 
system device; rather, it places the bootstrap task at the beginning 
of the memory image file created by phase l. 


2.4.2 System Generation Phase 2 (SGN2) 


Some of the functions necessary for a complete system generation must 
be performed on the target hardware configuration (creation of the 
checkpoint file, for example). Others are more conveniently performed 
under the target software configuration (installation of a large 
number of tasks, for example). Therefore, phase 1 of system generation 
creates a runnable IAS system with SGN2 installed and loaded into its 
partition. When the Executive Starts, it activates SGN2. 


SGN2 makes no modifications to the bootstrap program either in memory 
Or on disk. The only bootstrap-related aspect of SGN2 is the initial 
bootstrapping of the output file from SGN1. This bootstrapping causes 
SGN2 to become active. 
There are two methods of booting the output of SGNI1: 

1. By using the BOOT function, 


2. By using a combination of the BOOT function and the hardware 
bootstrap (ROM). 


Whichever method is used, the output of SGN1 must always be booted 
from the device that was specified as SY during phase l. 
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When the first method is used, all devices except the bootstrap device 
must be dismounted to ensure that all activity within the system is 
stopped. Then the BOOT function is requested and given the file 
specification of the image file to be booted. The BOOT task reads the 
first block of the image file into memory starting at real zero and 
begins to execute it. This process simulates the ROM bootstrap. BOOT 
does not require block zero of the device to have any special content. 
It uses the first virtual block of the image file specified. 


With the second method, BOOT is used to create a bootstrap block @ on 
the device. Then the device can be booted with the appropriate 
hardware ROM. BOOT accepts the file qualifier /WB following the file 
specification of the IAS image file to be booted. If this qualifier 
is present, the first block of the file is copied to block @ of the 
Same volume. This procedure does not perform a system reload, but 
does make the volume hardware bootable. 


The inclusion of the BOOT function allows the complete generation and 
testing of a new IAS system without changing the target device 
Substantially. The only modification to the target device is the 
creation of a new memory image file and installation of tasks into 
that system. Note that the disk files containing handlers and other 
system tasks are modified when they are installed into the new system. 
Therefore, even though it is possible to reboot a disk on which a new 
IAS image file has been created, care must be taken with such tasks as 
INS, ISMOU, and ISFCP, because their headers will reflect the new 
system. This problem can be circumvented by making separate copies of 
such tasks before running SGNI1. 


For further information about the BOOT command, refer to Appendix D. 


2.4.3 Saving a Generated System 


When SGN2 runs successfully, all the facilities of the generated IAS 
system are available. Once the user is satisfied that the system does 
perform as intended, it is necessary to dismount all devices and save 
the updated memory-resident system on the bootstrap device. Tf 
extensive testing of the new system is intended, it is advisable to 
Save the system first. 


The purpose of the SAVE function is to rewrite the file that was 
Originally booted. SAVE uses the bootstrap program that is 
permanently resident in low memory to perform this function. This 
approach insures the following: 


1. Only as much memory as specified during SGN1 is written, 


2. Memory is saved at the disk address (i.e., in the image file) 
from which it is to be booted. 


3. The device on which the file is saved is independent of any 
redirection of SY or other devices. That is, the save takes 
place on the device from which it was booted. 


Because the output of SAVE is an exact replica of memory, the IAS 


image file appears as a system with the SAVE task running. In order 
for SAVE to exit, it makes several modifications to the bootstrap in 


2=6 
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low memory after copying it into its own buffer to perform the disk 
write and before performing the actual save. These modifications are 
as follows. 


1. Store the content of user memory management register APRQ@. 


2. Store the re-entry address in SAVE which is relative to user 
APRQ. 


3. Modify an internal branch within the bootstrap so that a 
sequence of instructions to return to SAVE in user mode is 
executed after memory management is enabled. 


At this point, two versions of the bootstrap program exist in memory: 
the original within SAVE and a modified version beginning at real 
location Qg. 


SAVE now changes the I/O function code of its version from a read to a 
write, inhibits task switching and interrupts by raising the processor 
priority to 7, and executes its version of the bootstrap. Upon 
completion of the save to disk, SAVE executes the same code that it 
executes when rebooting the saved memory image, as described in the 
next section. 


2.4.4 Subsequent Rebooting of a Saved Image 


Regardless of which method is used to boot a saved IAS system, the 
bootstrap program that performs the read originally came from virtual 
block 1 of the file being booted. This bootstrap overlays itself with 
the beginning of the file it is reading. Since the only differences 
between bootstraps is in data, the instructions continue to execute. 


On completion of the read of the saved memory image, which is 
performed in 1K sections, the overlay copy of the bootstrap executes a 
sequence of instructions that returns to SAVE in user mode with task 
Switching and interrupts inhibited. SAVE then restores all volatile 
registers, restores the power recovery vector which was used to direct 
the bootstrap to SAVE, and performs a number of other functions not 
related to the bootstrap. Upon completion, task switching and 
interrupts are enabled and the Executive is started by simulating a 
power fail AST. Finally, SAVE prints the IAS sign-on message and 
exits. 


One of the other functions performed by SAVE is to check the existence 
of the system clock. Since IAS can use either a KW11-L or a KW11-P 
clock, SAVE first checks for the clock for which the system was 
generated. If this test fails, SAVE attempts to start the other type 
of clock. Therefore, it is possible to boot an IAS system that was 
generated and saved on a configuration with a different type of clock. 


CHAPTER 3 


SYSTEM DEFINITIONS 


This chapter describes the terminal handler parameters and system 
generation directives that the user must specify for Stage 1 of system 
generation. The IAS Release Notes contain system information needed 
to specify these parameters and directives. See the IAS Editing 
Utilities Reference Manual for information about the IAS text editors 
needed to modify system generation files. 


3.1 TERMINAL HANDLER PARAMETERS 


The terminal handler parameters specify the number of terminals 
attached to the system, the hardware interfaces used to attach them 
and other required special servicing such as dial-up. The parameters 
are contained in a parameter file called [311,14]ISTT64PAR.MAC, which 
the user must edit before starting Stage l. 


NOTE 


Decimal numbers in MACRO-11 source files 
are specified with a trailing decimal 
point. Otherwise the number is assumed 
to be octal. For example, 12% 
represents 12 decimal (14 octal). 


Table 3-1 on the next page describes the terminal handler parameters 
in [311,14] ISTT64PAR.MAC. See Appendix A for a listing of the file 
as it is distributed. 


Parameter 


TTYNUM 


DHUN 
DJUN 
DCUN 
DL11E 


DMPEA 


DIAL 


PGEN 


SECOND 


TMUNIT 


More information about hardware interfaces can be 
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Description 


The total 
be generated 


number of terminals for which the system is to 
(including the console terminal). 


The number of DH11 (and DM11-BB) (16-line) units. 


The number of DJ11l (16-line) units. 


The number of DCll (Single line) units. 


The number of DL11E (single line) units. 

The external page address of the DM11-BB unit attached to 
the first DH11, otherwise set to @ if no DM11-BB. The 
second DHl11 is assigned to the DM11-BB at DMPEA+1@, etc. 

9 if it is 


Non-zero if dial-up support is required; not. 


Non-zero if @ if none 


need parity. 


any DL11 terminals need parity; 


The interval in number of TMUNITS between modem (DLIIE, 
DM11-BB) inspections, that is, the interval at which a 
check is made for any dial up requests. If there is a 
request for a dial up connection, the "ring bit" is set. 


Bither 1 or 2 to indicate the time unit used to measure 


the interval between modem inspections where 
1 = Clock ticks (normally equivalent to line frequency) 
2 = Seconds 


obtained from the 


PDP-11 Peripherals Handbook. 


Table 3-1 | 
ss Terminal Handler Parameters | 
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3.2 SYSTEM GENERATION DIRECTIVES 


Phases 1 and 2 of Stage 1 system generation are accomplished by 
issuing a series of commands to the system. The commands issued 
during phase 1 are called directives and are described in this 
chapter. 


Phase 2 commands install all the tasks needed to complete the IAS 
system; these command are described in Chapter 5. One phase 2 
directive, *DELAY (see section 3.2.6), exists to cause a 1-second 
delay in the processing of the command that follows the directive. 
Some command sequences may fail if a *DELAY directive is not 
specified. 


Phase 1 system generation directives are divided into six categories: 
1. The TARGET directive that defines the target system device. 
2. The PDP1l directive that defines the computer to be used. 


3. The EXEC, SCOM, and PAR, directives that divide the computer 
memory into the Executive, the system communication area, and 
partitions, respectively. 


4. The DEV directives that define the system peripherals. 


5. The DPAR, CKPNT and SY directives that supply system default 
information, 


6. The INS directives that install tasks needed for phase 2. 


Regardless of whether the directives are to be typed in‘response to 
System generation requests or an indirect file is to be used, each 
category of directives is separated from the preceding category by a 
record containing only a slash (/). The end of input to phase 1 is 
indicated by a record containing two slashes (//). See the examples in 
Appendix A. 


Many system generation directives can have multiple parameter sets for 
a Single occurrence of the directive name. Multiple sets are 
separated from each other by backslash (\) characters. The examples 
below illustrate two PAR directives first and then the same two 
directives using the convention for multiple parameter sets. 


PAR=JIM,,,U 
PAR=JOHN,,,U 


Or 

PAR=JIM,,,U\JOHN,,,U 
To reach the point where the directives are entered, perform the 
appropriate steps as detailed in Chapter 6, section 6.1 through step 


8. At this point, the following message is printed on the terminal. 


SYSGEN PHASE] 
SPECIFY TARGET DEVICE AND FILENAME 
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TARGET 


3.2.1 Target Directive 


TARGET is an optional directive used to define the target device, that 
is, the device on which phase 1 is to create its output file and 
obtain all required tasks for installation. The TARGET directive has 
the following format. 


TARGET=xyn: [ufd] filename.ext 


where 
xyn: is the device mnemonic and unit number. The default 
is SY@. 
fufd] is the UFD under which phase 1 is to store the system 
file. The default is [11,17]. 
filename.ext is the filename and extension used to name the file 


created by phase 1. The default is IAS.SAV. 


Tf the TARGET directive is omitted, phase 1 uses the following file 
specification. 


SY@:[11,17] IAS.SAV 


3.2.1.1 Console Entry - When the message SPECIFY TARGET DEVICE AND 
FILENAME is printed on the console, the user can type the TARGET 
directive or the name of the indirect command file to be used. 
Alternatively, the user can type both or neither; see Chapter 6 
section 6.1, steps 12 and 13. To omit the TARGET directive, simply 
proceed to input the PDP-11 directive described in section 3.2.2. 


3.2.1.2 Description - If the TARGET directive is used, it 
completely describes where the output file of SGN1 is to be created 
and with what name. The following example creates a file named 


64KSYS.SAV on DBl under UFD [11,17]. 
SGN>TARGET=DB1:[11,17]64KSYS.SAV 


If TARGET directive has been entered from the console, SGNl prompts 
for the CPU specification, as demonstrated in the following example. 


| SGN>TARGET=DB1: [11,17] 64KSYS 
ENTER CPU SPECIFICATION 


SGN> 
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PDP11 


3.2.2 PDPl11 Directive 


The PDP1ll directive is used to define the target system processor 


configuration 


to system generation. One PDP11 directive is reguired. 


The directive has the following format: 


PDPll=cpu-type, [mem-size],[fpt-optn] , [clock-freq] 


cpu-type 


mem-size 


fpt-optn 


clock-freg 


45 to specify a PDP-11/45, or 78 to specify a 
PDP-11/78. 


physical memory size specified as nnnK words. nnn 
must be a decimal integer. The maximum value is 
124. If this parameter is omitted, 64K is used as 
the memory size. The mem-size specified must be 
equal to or less than the amount of memory on the 
target hardware. 


FP to indicate that the floating point option is 
available in the hardware; otherwise, the 
parameter is omitted. 


system clock ticks per second for the standard 
clock (KW11-L) or interrupts per second, clock 
identification, and clock ticks per interrupt for 
the programmable clock (KWI11-P). 


For the standard clock, specify a decimal number 
that is the line frequency (normally 5@ or 66). 
The system runs with the line freguency clock at 
the specified frequency. If the parameter is 
omitted, 58 hz is used. 


For a programmable clock, three decimal numbers 
are specified. 


l. Frequency of clock interrupts per _ second; 
e.g., 1000. 


2. Clock rate identification 


1900 KHz 

10 KHz 

line frequency 
external 


wou Ww i 


3. Number of clock ticks per interrupt 
The three numbers must be enclosed in angle 
brackets and separated by commas as in the 
following example: 

<100,0,1800>— 
The above example indicates that the programmable 


clock is to be uSed as the system clock. It is 
interrupting 100 times per second using the 1090 


Fas) 
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KHz clock with a count of 1909 loaded into the 
count register. 


3.2.2.1 Console Entry - When the message ENTER CPU SPECIFICATION is 
printed on the console, the user types the PDP1ll directive. Enter the 
PDP11 directive followed by a record containing only a slash (/) as in 
this example. 


SGN>PDP11=79 ,96K 
SGN>/ 
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3.2.3 Memory Allocation 


The memory allocation directives make it possible for the user to 
place the Executive and system common area in memory and to establish 
partitions. The allocation of memory is accomplished using the 
following directives: 


- EXEC (optional) 
- SCOM (required) 
- POOL (optional) 
- PAR’ (required) 


These directives can be entered either from within an indirect command 
file, or in any order in response to the following request that is 
printed on the console. 


SPECIFY DIVISION OF MEMORY 


The memory allocation directives must be followed by a record 
containing only a slash (/). 
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EXEC 


3.2.3.1 EXEC Directive - The EXEC directive is used to load the IAS 
Executive into memory starting at a specified 32-word boundary. An 


address higher than the bootstrap program must be used. See Chapter 
2, section 2.4.1 for bootstrap sizes. 


The EXEC directive has the following format. 
EXEC=base 
where 


base is a 32-word boundary at which the Executive is to 
start. The octal number specified in the EXEC 
directive is multiplied by 198 (octal) by system 
generation to determine the starting address. For 
example, if base is specified as 540, the starting 
address is memory location 54008 (octal). 


The EXEC directive is optional. If the EXEC directive is not 
included, the Executive starts at the next 32-word boundary after the 
bootstrap program and base addresses specified in subsequent 
directives are ignored. 


If the EXEC directive is included, a base address must also be 
specified in every directive that contains base as_ an optional 
parameter. 
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SCOM 


3.2.3.2 SCOM Directive - The SCOM directive allocates space for the 
system common area. The system common area comprises the system 
Subroutines, a communication region, the system tables (including the 
system task directory) and the node pool. The system common area 
cannot exceed 12K words. 


One SCOM directive is required. 

The SCOM directive has the following format: 
SCOM= [base] ,size,std-entries 

where 


base is the starting address for the system common 
area. This location is specified using the same 
conventions as for the base address in the EXEC 
directive. If the EXEC directive is included in 
system generation, the base parameter must be part 
of the SCOM directive. If this parameter and the 
EXEC directive are omitted, the system common area 
follows the Executive in memory. 


size is the total length of the system common area. 
The size can be specified as an octal number of 
32-word blocks or as nnK. When the form nnk is 
used, the number (nn) is multiplied by 1024 words 
to determine the desired size. The factors 
involved in determining the size of SCOM are 
detailed below in Section 4.4.1. 


std-entries is a decimal number equivalent to the number of 
system task directory entries. This parameter 
establishes the maximum number of 
simultaneously-installed tasks (user and system 
tasks) that the system is to support. 


SCOM Size - The size of the system common area is the sum of the 
following elements, 


1. The length in words of the system subroutines and the 
communication area, 


2. The number of tasks installed at any given time multiplied by 
16 words, 


3. The number of system task directory (STD) entries specified 
by std-size, above, 
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4. The number of DEV directives multiplied by 26 words, 
5. The number of PAR directives multiplied by 19 words, 
6. Size of the variable-length node pool. 


To determine the approximate amount of remaining space in the pool, 
Subtract items 1 through 5 from the SCOM size parameter as follows. 


Pool size = SCOM size - (sum of items 1 through 5) 


The node pool is used by the Executive and many of the system 
utilities as dymanic storage. Each node consists of a variable number 
Of 8-word blocks. If the system runs out of pool. space, its 
performance degrades and results may be unpredictable. Until 
experience is gained with the system, leave as much space as possible 
for the node pool. 


3-19 
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POOL 


3.2.3.3 POOL Directive - The POOL directive specifies the number of 
16-word nodes to be prepicked for the terminal handler. These nodes 
are picked by phase 2 of system generation and placed in a linked 
list. When the terminal handler picks a node from the pool at the 
interrupt service routine level, the node allocation routines supply 
such nodes from the prepicked list. 


Tne directive has the following format. 
POOL=xXxXx 
where 
XXX is an octal number representing the maximum number of 
interrupt service level nodes to be made available to 
the Interrupt Service Routines (ISR). xxx can be in the 


range from @ through 377 (octal). 


The POOL directive is optional. If it is omitted, system generation 
prepicks one 16-word node for each device named TTn. 


If xxx is 9, no nodes are prepicked for the terminal handler. 
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PAR 


3.2.3.4 PAR Directive - The partition directive establishes the 
name, base address, size, and type of every partition in the target 
system. Every partition in the system must be defined during system 


generation. 
Multiple parameter sets are allowed. 
The PAR directive has the following format. 


PAR=par-name, [base] ,size, [par-type] 


where 
par-name is anup to 6-character ASCII name _ for the 
partition. It is converted to a radix 59 name by 


the system. 


base is an optional starting address for the partition. 
This parameter is specified only if a base address 
is included in the EXEC directive and follows’ the 
same rules as those for the EXEC directive. 


Le base is omitted, the system places’ the 
partition optimally in memory. 


size is the size of the partition specified as an octal 
number of 32-word blocks or as nnkK. When nnk is 
used, nn is multiplied by 1024 to determine the 
desired size. 


par-type is the partition type: 


U for user-controlled, 
S for system-controlled, 
T for time-sharing. 


If par-type is omitted, U is assumed. 


See the IAS System Management Guide for information about partition 
types. 


NOTE 


The partition which contains the system 
disk handler (SYDISK) must not bea 
timesharing partition. The partition 
which will be used to run timesharing 
(interactive and batch) tasks must be 
defined as a timesharing partition. 
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DEV 


3.2.3.5 DEV Directive - The DEV directive is used to characterize 
completely each device n the system. Any device not defined by a DEV 
directive does not exist as far as IAS iS concerned. Information 
required for the DEV directive is contained in Table 3-2. Appendix B 
contains a listing of device characteristic words. Appendix C 
describes how to define the characteristic words of teleprinters 
connected to DH11 or DJ1l lines. 


The format of the DEV directive follows. 
DEV=xyn,type,vect,pri,ext-page[,devacp] 
where 


XY a 2-character ASCII mnemonic to be used to refer 
to the device. (See Table 3-2). 


n a l-or 2-digit octal unit number. 


type either a device type that phase 1 uses to 
determine the device characteristics or the actual 
device characteristics. Table 3-2 lists the 
device types recognized by phase 1. Appendix B 
lists the associated characteristics. 


If the four device characteristics are to be 
specified they must appear between angle brackets 
as in the following example. Also see Appendix C. 


DEV=XY@,<3,17,21,1000>,210,5,177009 


vect address of the device interrupt trap vector. See 
Table 3-2. 


pri The software priority at which the device’s 
interrupts are to be serviced. The user. should 
ensure that the software priority is equal to or 
higher than the hardware level at which the device 
interrupts unless the interrupt service routine of 
the handler is re-entrant. See Table 3-2. 


ext-page the external page address of the device 
controller. In most cases, ext-page is the lowest 
address when a device uses several external page 
addresses. See Table 3-2. 


devacp is an optional file primitives task name (or ACP 
name) for file-oriented devices. 


An ACP (ancillory control processor) is a task 
that assists a device handler in managing a 
file-structured volume. An ACP also is’ referred 
to as a file primitives task under IAS. 


If an ACP is not specified, phase 1 defaults to 


FI1LACP for directory devices and MTAACP for 
magnetic tape. 


3=L3 


Mnemonic 


DK 


(1) 
(2) 


(3) 
(4) 
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If an ACP task is specified, its name must be 6 
characters ending in ACP. The first three 
characters are stored in the PUD and used at mount 
time. The ACP task must be installed before the 
device can be mounted. 


_ rr a ae renga rere 


Table 3-2 
Device Information 


Normal External 
Type Vector Priority Page Address 
RK 3 5 177400 
RK@5 5 177460 
RFn (1) 5 177469 
RP9Q3B 5 176719 
RP@2 5 176718 
RS@3 5 172049 
RS@4 (2) 5 172040 
RPQ4 (2) 5 1767080 
KSR33 Float(4) 4 Float 
KSR35 Float 4 Float 
VTO5 Float 4 Float 
LA3@P Float 4 Float 
LA3@S Float 4 Float 
LA36 4 Float 
LP11A(8@8Col) 4 177514 
LP11B(132Col) 4 177514 
CR11 6 177169 
CR11 (3) 4 172460 
TU1O 5 172529 
TU16 5 172440 
PTR 4 177558 
PTP 4 177554 
DT11 6 177340 
TA11 6 177500 
AF11 4 172570 
AD@1 6 17677@ 
LPS1l 5 179409 
UDC11 6 171908 
None None None 


n = number of RF11l platters (1 to 8) 
These are disks on the RH11 massbus controller. 


The DB unit number must correspond to the number assigned by 
physical connection to the RH1ll. 


Use this information for the CD11. 


The console teleprinter does not float. Its vector is 6@ and 


its external page address is 177560. 
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NOTE 


For various combinations of the above 
devices, vector addresses and external 
page addresses may differ from those in 
Table 4-l. The correct vector. and 
external page address for any 
configuration can be determined by Field 
Service Engineers, Useful information 
can also be found in PDP11l Peripherals 
Handbook. 


Console Entry - Type the DEV directives in response to the following 
message. 


SPECIFY DEVICES 


When all directives are entered, type a record containing a slash (/). 
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3.2.4 System Default Specifications 


The next group of directives to 
defaults. The default directives 
either at the console or from within 
directives are: 


SY 
DPAR 
CKPNT 


be specified determine system 
may be specified in any order, 
an indirect command file. These 


A record containing a slash (/) must follow the last directive to be 


specified. 


If the user is entering the directives at the console, they follow the 


prompt 


SPECIFY DEFAULTS 


which appears after the last device directive has been entered. 
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SY 


3.2.4.1 SY Directive - The SY directive establishes the system disk 
to be used when phase 2 of system generation runs. The SY directive 
has the following format. 

SY=xyn 


where 


XY the 2-character mnemonic of the device. 


n = the unit number of the device. 


Phase 1 of system generation checks that the handler task for _ the 
device designated as SY is installed. For example, if DP@ is to be 
the system device, the user must install the handler DP.... during 
phase 1 of system generation (See section 3.2.6). 


Care must be taken to ensure that the correct device is assigned to 
SY. Phase 1 of system generation assumes that all tasks it installs 
are to be resident on the SY of the target system and creates STDs 
accordingly. . 


Since some of these tasks are required during execution of Phase 2, it 
is necessary to bootstrap phase 2 from the target SY device. See 
Chapter 2, section 2.4 on software bootstrapping of IAS. 
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DPAR 


3.2.4.2 DPAR Directive - The 
partition. Tasks and SGAs use the default partition if none other 


specified at installation, runtime or task build. 


DPAR directive specifies the default 
is 
The DPAR directive is required. 
The DPAR directive has the following format. 
DPAR=par-name 


where 


par-name is the name of the default partition. It must be 
a name defined by a PAR directive. 
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3.2.4.3 CKPNT Directive - The CKPNT directive enables checkpointing 
‘of real time tasks and specifies the disk and storage area to be 
allocated for checkpointing. 

The directive is optional. 


The CKPNT directive has the following format. 


CKPNT=dev,size 


where 
dev is the name of the device on which the checkpoint 
area is to reside. The device must be named in a 
DEV directive. 
size is the size of the checkpoint area. The size can 
be specified aS nnkK, where nn is the decimal 
number of 19024-word units, or as an octal number 
of 32-word blocks. 
Description - The device named for checkpointing must contain a 


Files-l1l structured disk. This disk volume must be mounted during 
phase 2 of system generation. To create a Files-ll structured disk, 
use the INI command in the SYSBLD.CMD command file that is executed 
during phase 2 of system generation or have a previously created 
volume on the device. The volume must be mounted during phase 2 of 
system generation, 


The use of checkpointing iS optional. However, if it is used, real 
memory space is allocated to support it. The amount of memory used 
depends on the checkpoint area of the disk. The relationshin is one 
32-word memory block for every 512K words of disk space specified for 
checkpointing. The checkpoint bitmap is at the end of the Executive. 
This memory allocation must be taken into account when specifying the 
size of partitions. 
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INS 


3.2.5 INS Directive 


The INS directive installs the system tasks needed to provide the 
target system with the capability to do useful work. All installs for 
a given partition must be on the same line.The INS directive has the 
Following format. 


INS=par-name,file-specifier,file-specifier,...,file-specifier 


where 
par-name is a partition name. 
file-specifier is an IAS file containing a task to. be 
installed in the named partition. Up to five 
Files can be specified in one INS directive. 
The file specifier must not include a device 
mnemonic and must be fewer than 32 (decimal) 
characters. 
3.2.5.1 - Console Entry - After the user has entered the default 


directives, the system prompts the message 
SPECIFY INSTALLS 


The install directives are then entered, followed by a= record 
consisting of 2 slashes (//). 


3.2.5.2 Description - Minimally, the disk driver (DK...., DP...., 
Or DB....), the teletype handler (TT....), the file system (F11ACP), 
and phase 2 of system generation (SGN2...) must be installed. The 
items in parentheses indicate the names of the specified tasks. See 
the INS directives in the system generation command files in Appendix 
A for examples. 


To obtain a list of system tasks that can be installed, print a 
directory of UFD [1l,l]. See Required Task Installations below. 


All tasks installed during phase 1 are assumed to be on the device 
specified in the TARGET directive. It is further assumed that they 
are to be on the target SY when phase 2 executes. 


No tasks installed during phase 1 can be bound to a shareable global 
area, nor can such tasks be multiuser. 


No more than 15 tasks can be installed during Phase 1 of system 
generation. During Phase 2, the number of installs is limited only by 
the number of entries allowed in the system task directory (STD). 
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3.2.5.3 Required Task Installations - At the completion of phase 
1, a target system exists that can operate as an independent IAS 
system. The final portion of phase 1 installs the tasks required to 
‘accomplish this end. 


When a task is installed, it is given an entry in the system task 
directory (STD). This entry allows the system to load the task without 
making use of the file system. 


Selection of tasks for installation depends on the following two 
factors: 


1. The capabilities defined for the target system, 


2. The procedures to be uSed in creating the operational target 
system. 


If the target system is to operate as an independent IAS system 
following bootstrap, it must have tasks installed in it that are 
capable of doing the required work. 


While processing the INS directives, phase 1 of system generation 
checks for the names of two system tasks: the disk handler for the 
system disk and phase 2 of system generation. These tasks are 
installed and are running when phase 2 is bootstrapped. The device 
handler is either DK...., DP...., DB.... depending on the device 
assigned to SY. Phase 2 of system generation is called SGN2. If these 
tasks are not named in the INS directive, the system is not 
operational when bootstrapped. 


Normally other tasks must be installed in addition to the disk handler 
and SG2... . Typically the following additional tasks (identified by 
their filenames) are installed: 


. Install (INS), 

- Mount (ISMOU), 

. File system primitives (ISBIGFCP or ISFCP) 
- Teletype handler (ISTT64), 


up to 15 tasks can be installed during phase l. 


File Primitives - Since phase 2 of system generation automatically 
mounts the system device, the appropriate file primitive tasks must be 
installed during phase 1. Two versions of the directory device file 
primitives are provided. Both have the task name F11ACP. One has the 
filename ISFCP.TSK. It is a small, heavily overlaid version of the 
task. The other is named ISBIGFCP.TSK and is minimally overlaid. 


If the user has his own file primitives, he should set the default ACP 
name in the DEV directive and install that task during phase l. 


Additional Tasks - With the minimum number of required tasks 
installed, the installation of any additional tasks can occur during 
phase 2. The decision to install additional tasks during phase 2 is 
partly procedural and partly due to the 15-task installation 
limitation of phase l. 
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* DELAY 


3.2.6 Phase 2 Directive (*DELAY) 


The *DELAY directive causes a 1-second delay in the processing of 
phase 2 commands. Phase 2 sequentially retrieves and executes MCR 
commands from a file named [11,17]SYSBLD.CMD. Some command sequences 
may fail if a delay is not interposed between them during their 
execution. For example, the following Sequence issued to replace a 
device handler initially loaded by phase 2 of system generation. 


l. Request the new device handler. 
2° Unload the existing device handler. 


os Specify several delays to give the system time to install and 
run the new device handler. 


Without the delays, the next MCR command may fail due to the 
nonexistence of a necessary handler. 


The *DELAY directive has no parameters. 


CHAPTER 4 


TIMESHARING EXECUTIVE PARAMETERS 


The purpose of Stage 2 system generation is to revise the Timesharing 
Executive so that it reflects current installation interactive and 
batch processing requirements. The user specifies the installation 
requirements by editing a MACRO source file called 
[311,107] SGDATA.MAC. The file contains the parameters needed by IAS to 
control timesharing activity. 


This chapter defines the individual timesharing parameters. The IAS 
System Management Guide describes how to set the parameter values to 
produce a Timesharing Executive tailored to the needs of the 
installation. The parameters define the IAS data structures contained 
in the libraries IASCOM and IASBUF. The data structures are described 
in Chapter 9 of the IAS Executive Reference Manual-Volume II. They 
include 


1. The User Job Node (UJN) 

2. The User Terminal Node (UTN) 

3. The Command Interpreter Table (CIT) 

4. The Device Table (DVT) 

5. The User Task List (UTL) 

6. The Swap File Table (SFT) 

7. The Job Node Pool (JNP) 

8. The Terminal Node Pool (TNP) 
Stage 2 determines the size and contents of all the tables, lists and 
node pools. Parameters that determine the contents may be overridden 
at System Startup, but Stage 2 system generation must be performed in 
order to change the size of tables, lists and node opools and the 


number of nodes within a pool. Each description of the parameters 
below includes the equivalent Startup command if one exists. See the 


IAS System Management Guide for System Startup information. 


Note 


SGLUN 


SGUVL 


SGDEV 


SGTMM 


SGXBF 


SGATT 
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that: 

1. Timesharing terminals include any device from which a Command 
Language Interpreter (CLI) can receive input, for example, a 
card reader (CR), a teleprinter terminal (TT) or spooled 
input (SP). 

2. Decimal numbers in MACRO-11 source files are specified with a 
trailing decimal point. Otherwise the number is assumed to 
be octal. For example, 12. represents 12 decimal (14 octal). 

SET-UP PARAMETERS 


The maximum number of luns that each user can have assigned 
at anyone time. In PDS terms this means the maximum number 
of lun assignments which can be made with the ASSIGN 
command. 


SGLUN generates the lun table section of a terminal node. 


The maximum number of devices that each user can have 
allocated at any one time. 


SGUVL generates tne device map table in the terminal node. 


The maximum number of devices which may be available for 
interactive and batch jobs. Can include terminals if they 
are not timesharing terminals. 


SGDEV generates the available device section of the DVT 
table with the specified number of entries for non-terminal 
devices. 


The maximum number of timesharing terminals to be supported 
at any one time. 


SGTMM generates additional entries in the DVT for terminal 
devices and a User Terminal Node (UTN) for each terminal. 


The number of timesharing buffers. Should normally the sum 
of the active terminals (SGATT) and the number of non-CLI 
timesharing tasks (SGXTSK) + 1. 


SGXBF generates the buffer pool (IASBUF) used by Command 
Language Interpreters (CLIs) and Timesharing Control 
Primitives (TCP). 


The number of active timesharing terminals at any one time. 
This parameter generates one job node (UJN) for each CLI 
task and will normally be set equal to SGTMM. 


SGXTSK 


SGTKSZ 


SGBUF 


SGCIT 


SGUTL 
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The number of non-CLI timesharing tasks. This parameter 
generates the specified number of job nodes (UJNsS) in 
addition to those allocated for CLIs. In a PDS system where 
at present each active PDS CLI requires one additional job 
node this parameter would be set equal to SGATT. 


The maximum swap size allowed for a timesharing task in 
units of 32 decimal words or 199 octal bytes. A task with a 
Swap size exceeding the specified size will not be allowed 
to execute. 


Equivalent start-up command is SET SWAP. 


The number of bytes available in a timsharing buffer. The 
system will ensure that this value is even and not less than 
80 bytes. 


The maximum number of CLIS which can be concurrently 
declared to the system via the System Control Interface. 
Should be a minimum of 2 to allow SCI and PDS to be 
concurrently declared. 


SGCIT generates the Command Interpreter Table (CIT) with the 


specified number of entries. 


The number of timesharing scheduling levels. Must be 2 or 
more if interactive jobs are to be given preference over 
batch jobs. 


SGUTL generates the User Task List (UTL). 


4.2 SCHEDULING PARAMETERS 


SGSPR 


SGSTK 


SGCON 


SGTSL 


Ticks between scheduler promotions. The number of ticks of 
elapsed time after which the scheduler will promote a task 
up one level if no task at that level has been scheduled. 
Equivalent Startup command is SET QUANTUM. 

Scheduler idle time. Should be set tol. 


Quantum constant. The minimum time quantum given to a job 
when it is scheduled. 


Equivalent Startup command is SET QUANTUM. 


Maximum time slice. The maximum number of ticks a task can 
run before a timesharing reschedule will occur. 


Equivalent Startup command is SET QUANTUM. 


SGAFM 


SGBSH 


SGBOT 


SGTIPR 


SGPIPR 
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Allocation factor memory size. The number of 32 decimal 
word blocks (or 198 octal bytes) of memory used to allocate 
guanta in relation to task size. 

Equivalent Startup command is SET QUANTUM. 

Allocation factor ticks/memory size. The number of ticks 
allocated per unit of memory as specified by SGAFM. For 
example: if SGAFM = 32 (32 * 32 = 1924 words) and SGAFT = 2 
then 2 ticks of CPU time will be allocated for each 1K words 
of the task. 

The number of ticks between batch schedules. 

Equivalent Startup command is SET BATCH. 


The number of ticks of CPU time allocated to batch each time 
it is scheduled. 


Equivalent Startup command is SET BATCH. 


The priority of TS5S1 in the Active Task List (from 2. to 
240.). 


Equivalent Startup command is SET PARTITION. 


The priority of the TCP handler in the Active Task List 
(from 2. to 240.). This value must be higher than SGTIPR. 


Equivalent Startup command is SET PARTITION. 


4.3 SWAPPING PARAMETERS 


SGSPR 


SGLBSZ 


SGFLSZ 


The maximum number of swap files which will be used to 
create the swapping space. 


The logical swap block size. This is the number of physical 
disk blocks (256 words) which comprise one logical swap 
block. For example, if SGLBSZ = 4 the task swap areas will 
be allocated in 1K word units. 

Equivalent Startup command is SET SWAP. 


The maximum size of any of the swap files. Specified in 
terms of logical swap blocks. 


Equivalent Startup command is SET SWAP. 


CHAPTER 5 


TRANSFERRING THE DISTRIBUTED SYSTEM 


This chapter lists the steps to be followed to transfer the IAS system 
distributed on magnetic tape onto the system disk, either an RK@5, 
RP§92, RP@3 or RPO4. 


Most of the commands contained in this chapter and Chapters 6 and 7 
are issued to the Monitor Console Routines (MCR) (see Appendix D). MCR 
is the interface used for system generation and startup. MCR is 
designed to time out after five minutes. When this happens, as 
indicated by a carriage return and line feed, ovress CTRL and C 
Simultaneously to reactivate MCR. Because the timeout interval starts 
when the MCR prompt (MCR>) is printed, it is possible for MCR to time 
out while the user is typing a command; in this case the entire line 
must be retyoed. 


5.1 HARDWARE BOOTSTRAP 

In order to transfer the distribution medium onto the system disk, the 
distribution medium must be bootstrapped. Four models of hardware 
bootstraps are available on systems used for IAS: MR1L1DB, BM792YB, 
BM873YA and BM873YB. The type of bootstrap for a particular PDP-11 
can be determined by consulting the equipment order. 

Whenever a request to bootstrap the system iS encountered in the 


following text, refer to one of the four sections that follow to 
perform the appropriate bootstrap. 


5.1.1 MRI1IDB Bootstrap 


Perform the following steps to uSe an MR11DB Bootstrap. 
1. On the console switches, set HALT. 
2. Set ENABLE. 
3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 5-1 provides the 


device addresses. 


A. Press LOAD ADDR. 


5-1 
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5% Press START. 


Table 5-1 
Device Addresses for the MR11DB Bootstrap 


Device Address 


RP@3 Disk 173154 


RK Disk 1731190 
RF Disk 173190 
TU1L2 Magnetic Tape! 173136 


DECtape 173120 


5.1.2 BM792YB Bootstrap 
Perform the following steps to use a BM792YB Bootstrap. 
1. On the console switches, set HALT. 
2. Set ENABLE. 
3. Enter 173198 into the display switches. 
4. Press LOAD ADDR. 
5. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 5-2 provides the 


device addresses. 


‘ Press START. 


Table 5-2 
Device Addresses for the BM792YB Bootstrap 


Device Address 


RP@3 Disk 176716 


RK Disk 177406 


RF Disk 177462 


177344 


DECtape 
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Magnetic tape cannot be booted with the BM792YB Bootstrap. To 
bootstrap from a TU19 perform the following sequence of operations. 


Mount the magnetic tape reel containing the distribution system on 
Magnetic tape unit @. The tape must be at the load point. Turn the 
unit ON LINE. (For more detailed instructions see the magnetic tape 
hardware manual.) 


Move the CPU ENABLE/HALT switch to its HALT position. 


Deposit the following routine in memory via the console = switch 
registers. 


Address Contents Symbolic 
18009 12780 MOV #172524,R@ 
199982 172524 

19004 5319 DEC (R@) 

18006 1274@ MOV #690011, (R@) 
18010 69911 

10812 1357190 TSTB (RQ) 

10014 100376 BPL .-2 

19016 57190 TST (RO) 

19020 100767 BMI .-29 

10022 12719 MOV #60003, (RO) 
10024 60993 

19926 105710 TSTB (RQ) 

1096390 100376 BPL .-2 

19932 5719 TST (RO) 

19034 198777 BMI . 

10036 5807 CLR PC 


ai Set the CPU Switch Register to 910000. 
2 Depress the LOAD ADDR switch. 
ce Move the CPU ENABLE/HALT switch to its ENABLE position. 
4. Depress the CPU START switch. 
If the machine hangs in the RUN state at location 19834, a magnetic 


tape error has occurred. Halt the machine, rewind the magnetic tape 
manually, and restart the bootstrap procedure. 


5.1.3 BM873YA Bootstrap 
Perform the following steps to use the BM873YA Bootstrap. 
1. On the console switches, set HALT. 


2. Set ENABLE. 
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3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 5-3 provides the 
device addresses. 


4. Press LOAD ADDR. 


NOTE 


If a unit other than @ contains’ the 
device to be booted, set the switch 
register to the unit number of the 
device to be booted before pressing 
START. 


5 Press START. 


Table 5-3 
Device Addresses for BM873YA Bootstrap 


Device Address 


(RFn disk) 773009 


RP1l (RP@3 disk) 773199 
RK11 (RK@5 disk) -- Unit @ 773018 

Unit specified in Switch register 773029 
TCll (DECtape) 773030 


(TUL® magnetic tape) 773959 


5.1.4 BM873YB Bootstrap 
Perform tne following steps to use the BM873YB bootstrap. 
1. On the console switches, set HALT. 
2. Set ENABLE. 
3. Enter the address of the device from which the bootstrap is 
to occur into the console switches. Table 5-4 provides the 


device addresses. 


4. Press LOAD ADDR. 


NOTE 
If a unit other than @ contains the 


device to be booted, set the switch 
register to the unit number of the 
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device to be booted before pressing 
START. 


5 Press START. 


Table 5-4 
Device Addresses for BM873YB Bootstrap 


Device Address 


RH11 (RS#3,4 disk) -- unit 9 773090 


Unit specified in switch register 773802 


RK11 (RK@5 disk) -- unit @ 7739030 
Unit specified in switch register 773032 
RH11 (RP@4 disk) -- unit 9 773329 
Unit specified in Switch register 773322 
RP11l (RP@3 disk) -- unit 9 773350 
Unit specified in switch register TIS S02 
RF11 (RS11 disk) 773136 
TCll (DECtape) 773970 | 


TM11 (TU1L® magnetic tape) 773119 


RH11 (TUL6/TM@O2 magnetic tape) 773150 
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5.2 TRANSFERRING THE DISTRIBUTION MEDIUM FROM MAGNETIC TAPE 
The following paragraphs detail the procedures to be used to transfer 


a distribution system from magnetic tape onto an RK@5, RP92, RP@3 or 
RPG4 system device. 


5.2.1 Bootstrapping the Distribution Tape 
1. Place the distribution tape on unit Qg. 


2. Bootstrap the distribution tape following the procedures in 
Section 5.1. The system prints the following on the console: 


IAS SYSTEM DISTRIBUTION TAPE 
SYSTEM DISK? 


3. Respond with one of the following to indicate the type of 
system disk: 


RK@5 for RK@5 system disk 
RP@2 for RP@2 system disk 
RPO3 for RP®@3 system disk 
RP#4 for RPG4 system disk 


4. Once the name of the system device has been typed, the system 
prints the following message or its equivalent: 


LOAD SCRATCH DISK ON xy@ WRITE ENABLED 
TYPE °“CR° WHEN READY? 


where xy is the device type. 


5. When the disk is ready type carriage return, and if the disk 
can be formatted, the system prints the following: 


FORMAT DISK? 
6. Respond with one of following: 


YES to format the system disk. 
NO if disk formatting is not required. 


7. The system then formats the disk if so requested and prints 
the following message: 


RUN “BADBLOCKS‘? 
8. Respond with one of the following: 


YES to run the bad block utility on the system 
disk 


NO if this utility is not required 


1d. 


ll. 


12. 


13. 
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The system tests the system disk for bad blocks if this 
option was selected and then types: 


STANDARD VOLUME INITIALIZATION? 
Respond with one of the following: 
YES if standard volume initialization reguired 


NO to make the initialization task prompt for 
the initialization parameters. 


See Appendix D for a description of the MCR command 
INITIALIZE VOLUME. 


The system is then created. The information in Figure 5-1 is 
printed on the console while the system is created. When the 
system prints the following message the system building 
procedure is complete. 


***kEND OF SYSTEM GENERATION PHASE 2*** 


The system should be saved by typing CTRL/C to invoke MCR and 
by typing the following commands: 


MCR>TIM dd-mm-yy hh:mm:ss 
MCR>DMO- SY: 
MCR>SAV 


The system is now ready for use. It is a single user system 
which can be used to generate a_ system tailored to the 
installation’s hardware and software requirements. 
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TAS SYSTEM CISTRIBUTION TAFE 


SYSTEM CICK? RPGS 

LOAD SCRATCH DISK ON DFG WRITE ENABLED 
TYPE “CR’ WHEN READY? 

FORMAT DISK? NO 

RUM “BADBLOCKS’ ? NO 

STANGARD VOLUME INITIALISATION? YES 


REG DF=cy' 
INT SY: TASSYS-BADH=C AUTO) 
INI ~- CHECKING DF@: 
MOU SY: “OVR 
MOUNT—##VOLUME INFORMATION: 
DEVICE =bF6 
CLASS =FILE 14 
LABEL =TASSYS 
UIC =C4i,412 
ACCESS =CRWED, REWEO, ENED, RWED} 
CHARAC =€ 9 
UFD SY:04.21°FPRO=C RWED, RWED, RE] 
UFO CV:04, 21°F RO=C€ RWED, RWED, RR 
UFO SY:04, 32 
UFD SY:04, 4I-FRO=-f RWED. RWED, RWEO, RWED 
UFD CY:C4. SI°PRO=C( RWED, RWED, R, RJ 
UFO SY:C4,6]¢°FRO=0 RWED, RWED, RWED, RWEC 
UFD SY :04, 1@@I1¢PRO=0 RWED, RWED, RWED, RHED } 
UFD £:04,416412 
UFO 4':044,47 
UFO £:04141,4147 
UFO SY:0414,418) 
UFO SY:£44,472 
UFO CW:04141, 168) 
UFO SY:0414,1617 
UFO SY:044,182 7 
UFO SY:0441,1863) 
UFO SY:0414,168) 
UFO £Y:£14,1662 
UFO SY:044, 167) 
UFO £Y:0444,1473 
UFO SW:0411,45)7 
UFO SY:0414,473 
UFD £Y:0414141,1662 
UFO £¥:01441,1613 
UFO SY:04111,1627 
UFO £Y:0444,1637 
UFD S¥:0141,165) 
UFO £%:0111,1062 
UFO €Y:£1414, 1672 
UFO SY:30 268, 266) 
UFD SW:Ce14,14) 
UFD SY:f211,1872 
UFD SY:0314,414] 
UFO SW:0344,167 9 


CFY -- STARTING COFY' 
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CFeY -- COFY COMPLETE “ALLOW TAFE TO REWIND? 


REC OF=S%' 

MOU SY: “OVE 

MCUNT—##VOLUME TNFORMAT I OMe: 
CEYICE =DF& 


CLASS =FILE i1 
LABEL =TASSYS 
uIC =C4,12 


ACCESS =CRWEO. RWED, RWEO, RWECD J 
CHARAC =f ] 

INA CYSRES@LICACCHROCUICEHEL AL, 12 

THe C414, 431NS 


UNF ... RED... INR... . MOQU,... UNF 
INS Cid, LICREURPFeTASKS. .. CRE 
CRE 


INS €141,. 1 3LER 

INS Cia. 22F1TF 

LEE SYSLIBA(CO: 3G. - 2606. : 756. =SYSLIEB 
FIF SYSLIE. OLE-“FU 

INS C14. 11600 

INS Cia. 231INV 

INS Cad, LAISGNI-ATASE=... SGA"UICHE£ 11,17] 
SG1 @SY:0241. 1" IRFGSLEdk 

Siem 45, 64k 


SCOM=, S46, 96 
PRR=SYCOSK, » 5, U 
FARH=SYS,,14144,.T 
FPAR=FILE,, Led, U 
PAR=TTY, » 1360 U 
oe GEN, ,. 244%, T 


DEY =[KE, REGS. 2G, 3, 1° "498 
CEVSGKL, REGS, eG. 3. 1° 749 
DEV=DFPG, RPGSE, 254.5, 1°6°18 
DEV=TTE. LASGS, 6a, 4, Lersee 
DEV=LFG, LFLLE, eae, 4. 1° F514 
DEV=OTE, OTL, 214.6. 1° FP S4a 
CEV=O0TL, OT1L, 214.6, 1° F346 
CEVSEMTa, TULLE, eed, 5, 1° 2528 
CEV=MMa, TULE, ged, 5S. 1 re244do 
DEV=HMC, 5... 

DEV=SP, (10608, 6,0, 8>,,, 
GDEV=FI,,.; 

ial =TMs.5, 


OP AR=GEN 

CKENTH=0FE, Sek 

CY=OF 

e 

INGS=SYCOSKE, C141, 1 9DF 

INS=GEN, Ci, LP ISGN2,041, LITISMOU, CAL, LP TIN2“UICH04, 19 
INS=FILE, (11, 1 21ISFCF 

INS=TTY. 042, L.I31STT64 


ae 
ce 


SGN>END GF FHASE 1 
BOO SY:044. 1° 1AS. SAVPME 
BOQ SY: 
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wee CYCTEM GENERATION FHASE 2 *4+ 
MOU CPG: WOVE 
MHOUNT-* VOLUME INFORMATION 
DEVICE =DFG 


CLASS =FILE 12 
LABEL =TRESYS 
UIC =€1,12 


ACCESS =CRWED, RWED. RWED. RWED 2 
CHARACG =C] 

INZ Cid, LIMCR 

INZ SYSRESCLI“ACC=RO-UICEL 1, 1) 

*DELAY 

INZ Cit, LIINS 

*DELAY 

INS Cit, LIFIX 

*DELAY 

FIX FALACF 

*OELAY 

INS IASCOMCLICACCEROUICEL 4, 12 

INS LASBUFPLICACCHROCUICEL 4, 41) 

INS POSLIBSLICACCHROPUICEL 41, 1) 

*DELAY 

INS CAL, LI15DT 

INS C14, 270K 

INS Cid, LILF 

INS C44, 4140 

INS C44,4118TuUAG 

INS Cid, 41S TUG 

INS Cid, 4 QUE 

INS C14, 471SSFR 

INE C1it, LISFRE 

INS C414, 4I1S0FR 

INS Cid, 43TKTN 

INS C41, 17ABO 

INS C14, 4IACT 

INS Cit, 4]ALT 

INS C414, 47800 

INS C44, ICOM 

INS Cid, L11S0E¥ 

INE C4id, LITSOMO 

INS Cid, 2IEDT1 

INS Cid, LIFLX 

INS Cid, LIFL1MSG 

INS C44, 2]1NI 

INS C44, 2IL0A 

INS C44, 4]LUN 

INS C44, 4 FURMAC 

INS Cit, LIOFE 

INS Cid, 1IFAR 

INS Cid, LIFURFIF 

INS Cid, LIREA 

INS C14, 431SRED 

INS Cit, 43REM 

INS C44, 4 7RUN 

INS Cia, 13S5AV 

INS Cit, LISET 

INS C44, 11SLF 

INS C414, L1TAS 

INS C44,41TIM 
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INS C11. 1 7UFC 

INS C11, 2 7UNF 

INS C42. 2 7UNL 

INS Cit, LIUSERS 

INS C41, 22ACCOUNTS 

INS C14. LIRESET 

INS €4141,23SC1 

INS C411. 231AS 

INS C44. LILTASTART 

INS C11. LITCF 

IMS Cia, L3TSS1 

INS €141,.223TSSs 

INS C44. LITSSNUL 

INS C14, 2ITKE 

INS C44. 2 70MF 

INS C14, LILER 

* DELAY 

REM ... IMe 

*DELAY 

*#DELAY' 

etok ENG OF SYSTEM GENERATION FHASE @& #4 
MNCRSTIM SNOW FS 1° :6°6 
MCRSDMG SY: 

CM -- DFG: a GCISMOUNT COMPLETE ++ 
MCR 


Figure 5-1 
IAS Bootstrap 


CHAPTER 6 


STAGE 1 PROCEDURES 


IAS provides two tasks (phase 1 and phase 2) and a set of command 
files for Stage 1 of system generation. Its purpose is to create a 
file on disk that is an IAS system capable of running on the target 
hardware configuration. 


Phase 2 of system generation is designed to perform those functions 
that require the target configuration. Phase 2 is a task that is 
activated in the system created by phase l. 


Phase 1 (SGN1) should be the only task running in the system. 


Both phases accept input from command files. Phase 1 also accepts 
input from a terminal. (See Chapter 3, section 3.2 for details on 
console entry.) The distributed system includes several system 
generation command files under UFD [11,17]. The command files that can 
be used as input to phase 1 all have the following format for the 
filename and type. 


diskcnnk.CMD 


disk is the disk type that is to be the system device, that is, 
RK@5, RP®@2, RPO@3 or RPO4. 


Cc is the clock type; L for line clock or P for programmable 
clock. 


nn is the amount of memory supported by system generated using 
this file. 


Any one of these files can be uSed aS input to phase l. 
Appendix A provides sample listings of the files. 


The phase 2 input file is SYSBLD.CMD. It is located under UFD [11,17]. 
Phase 2 automatically uses this file to create a running system on the 
target hardware. SYSBLD.CMD can be edited prior to running phase 2 to 
reflect local requirements. Appendix A contains a listing of 
SYSBLD.CMD. 
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6.1 PHASE 1 OF SYSTEM GENERATION 


Phase 1 of Stage 1 of system generation uses the defaults of the | 
system under which it is running and communicates with the user on the 
console terminal. The purpose of phase 1 is to create a file on a 
disk. Once the file is created, the disk is called the target system 
disk. 


Care should be taken if the target system disk and the host system 
disk are the same; several tasks are installed in the target system 
during phase 1 that are also installed in the host system. Since task 
headers are modified by the install function, a task installed in one 
operating system cannot be used in another even though it was 
installed there previously. Device assignments, for example, may be 
different. 


NOTE 


Throughout this manual, the use of lower 
case letters in command strings 
indicates that the uSer is to supply the 
appropriate variables at that point in 
the command. For example, in the 
following MCR command, the user is to 
specify the device type and unit of the 
target disk. 


MCR>MOU target disk 
could be typed as 


MCR>MOU DPQ: 


The procedures for executing phase 1 on a running IAS system follow. 


1. Install system generation phase 1 and a special version of 
the install function as follows: 


MCR>SET /UIC=[1,1] 
MCR>INS [11,1] SGN1 
MCROINS [11,1] INV 


2. If the target disk is the current system disk, go to step 5. 
Tf steps 2 through 4 have been done previously, go to step 5. 
Otherwise, initialize and mount the target disk, as follows: 


MCR>INI target disk Use any appropriate INITVOL 
options (see Appendix D). 


MCR>MOU target disk Use any appropriate MOUNT 
options (see Appendix D). 
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3. Create the required UFD’s the disk the 


following commands: 


on target using 


MCR>UFD 
MCR>UFD 
MCR>UFD 


MCR>UFD 


MCR>UFD 
MCR>UFD 
MCR>UFD 


MCR>UFD 


target 
target 
target 


target 


target 


target 


target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 
target 


target 


disk[1,1]/PRO=[RWED,RWED,R,R] 
disk[1,2]/PRO=[RWED,RWED,R,R] 
disk[1,3] (for Verify) 


disk[{1,4]/PRO= [RWED,RWED,RWED,RWED] 
(to allow spooling) 


disk[1,5]/PRO=[R,RWED,R,R] 


disk[1,6] /PRO=[RWED,RWED, RWED,RWED] 
(for error logging) 


disk[1,19@] /PRO=[RWED,RWED,RWED,RWED] 
disk[1,101] 
disk[11,1] 
disk[11,14] 
disk[11,15] 
disk[11,17] 
disk[11,198] 
disk[11,191] 
disk[11,192] 
disk[{11,193] 
disk[11,195] 
disk[11,106] 
disk[{11,1907] 
disk[{111,14] 
disk[{111,15] 
disk[111,199] 
disk[111,191] 
disk[111,192] 
disk[111,193] 
disk[{111,195] 


disk[111,196] 
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MCR>UFD target disk[111,197] 
MCR>UFD target disk[211,14] 
MCR>UFD target disk[211,197] 
MCR>UFD target disk[311,14] 
MCROUFD target disk[311,1987] 

4. Transfer all files required for the target system. Both the 
target disk and the current system disk must be write 
enabled. 

MCR>SET /UIC=[1,1] 

MCR>PIP target disk =*.* 

MCR>PIP target disk[{1,2]=[1,2]*.* 
MCR>SET /UIC=[11,1] 


MCR>PIP target disk[1,100]=[1,100]*.* 


MCR>SET /UIC=[11,17] 
target disk=*.TSK 


target disk=*.STB 


= |= (|S 
QO QD Q 
DA jw lw 
Vo OW 
tg 'g 'g 
HH H 
ae) tg a) 


target disk=*.CMD 


MCR>SET /UIC=[1,1] 


MCR>PIP target disk[1,181]=[1,101]*.* 
MCR>PIP target disk[11,1]=[11,1]*.* 
MCR>PIP target disk[{11,100]=[11,100]*.* 
MCR>PIP target disk[11,101]=[11,101]*.* 
MCR>PIP target disk[11,1982]=[11,102]*.* 
MCR>PIP target disk[11,103]=[11,103]*.* 
MCR>PIP target disk[11,105]=[11,105]*.* 
MCR>PIP target disk[11,196]=[11,106]*.* 
MCR>PIP target disk[11,107]=[11,107]*.* 


MCR>PIP target disk[311,107]=[311,197]*.* 
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MCR>PIP target disk[311,14]=[311,14] ISTT64PAR.MAC 
MCR>PIP target disk[311,14]=[311,14]1ISTT64.MAC 
MCR>PIP target disk[311,14]=[311,14] ISTT64MAC.CMD 
MCR>PIP target disk[11,14]=[11,14] ISTT64TKB.CMD 


The files on the target disk are now available to be used to 
generate the new system. The pseudo device ‘SY’ should be 
redirected to the target disk by entering the following 
commands. The reedirect will cause all subsequent operations 
which do not explicitly specify a device name to default to 
the target disk. 


= 
Q 
wm 
Vv 
0 
= 
Oo 


SYY-: 

CR>DMO target disk: 
CR>RED target disk=SyY 
MCR>MOU target disk 
CR>MOU old system disk 


= 


| 


= 


| 


| 


= 


The terminal handler parameter file [311,14] ISTT64PAR.MAC, 
should be edited to specify the terminals and interfaces of 
the target system. If it is not necessary to change the 
terminal handler proceed to step 7. The parameters’ are 
described in Chapter 3, section 3.1. The following commands 
will perform all operations from the target disk. 


MCR>SET /UIC=[1,1] 
MCR>EDI [311,14] ISTT64PAR.MAC 


When the file has been edited the new terminal handler can be 
assembled and built by issuing the following commands. 


MCR>MAC @[311,14] ISTT64MAC 
MCR>TKB @[11,14] ISTT64TKB 


A new version of the terminal handler [11,1]ISTT64.TSK, now 
exists on the target disk. The size of the handler is 
variable according to the parameter settings. This size 
should be determined in order to generate the target system 
with a partition of the correct size to hold the teletype 
handler (TTY partition). 


If the TTY partition is larger than the size of the handler 
space in the partition may remain unused. If the TTY 
partition is smaller than the size of the handler ae fatal 
error will be produced by SGNIl. 


The size of the terminal handler can be easily determined by 
installing it with a temporary task name, issuing a TASK 
command and removing the task. 


STAGE 1 PROCEDURES 


For example, 


MCR>INS [11,1] ISTT64/TASK=AAAAAA/PAR=GEN 
MCR>TAS 
AAAAAA V@G4A GEN 248 152080 DB @6-90B00007202 


MCR>REM AAAAAA 


The printing of the complete task list can be suppressed by 
typing CTRL/O. In the above example, the handler size is 
152008 octal bytes; therefore, the size of the TTY partition 
should be set to 152. 


The command file to be uSed aS input to phase 1 should be 
edited to define the target system. If a suitable file 
currently exists proceed to step 8. The following commands 
should be used to run the editor: 


MCR>SET /UIC=[1,1] 
MCR>EDI [11,17] command file 


It is important to check that the following conditions are 
satisfied: 


a. The size of the SYDISK partition is large enough to hold 
the system disk handler. 


b. The SYDISK partition is not timesharing controlled. 


c. The TTY partition is large enough to hold the terminal 
handler (see step 6). 


d. The SY directive correctly names the target system disk. 


e. The disk handler for the target system disk is installed 
during phase l. 


f. The CKPNT directive names the correct device on which to 
create the checkpoint area (normally the target system 
disk). 


If the sizes of any partitions are changed (for example, TTY) 
the size of other partitions (for example, GEN) must be 
altered correspondingly. 


Depending on the available pool size of the host system, it 
may be necessary to remove some tasks from the host system. 
Chapter 2, section 2.2, provides guidelines for calculating 
node pool usage during system generation. 


A file under [11,17] called SYSGENREM.CMD can be used to 


remove tasks. It is advisable to use this file, Enter the 
following command to remove installed tasks using 
SYSGENREM.CMD. 


MCR>REM @[{11,17] SYSGENREM.CMD 


16. 


li. 


12. 


13. 


STAGE 1 PROCEDURES 
If FL1ACP has not been fixed in memory, fix it using’ the 
following command. 
MCR>FIX F1L1ACP 


This step is recommended for target system generations and is 
necessary if generating on the current system disk. 


At this point, phase 1 of system generation can be executed. 
It is preferable to execute it under UIC [11,17]. Use the 
following command to set the UIC. 

MCR>SET /UIC=[11,17] 


Run phase 1 ensuring that the command is terminated by 
pressing ““Altmode (ESC). 


MCR>RUN SGN1 Depress Altmode 
The system responds as follows. 

SYSGEN PHASE 1 

SPECIFY TARGET DEVICE AND FILENAME 

SGN> 
At this point, the user has the option of naming the device, 
UFD, and filename to be assigned to the file produced by 
phase 1. The directive has the following format. 


SGN>TARGET=td: [ufd] filename 


td indicates the target disk. If it is omitted, 
SY is used by default. 


[ufd] is the UFD of the system image file. If it 
is omitted [11,17] is used. 


filename is the name to be assigned to the file. If 
it is omitted, IAS.SAV is uSed. 


If the TARGET directive is not specified, the default is 
SY: [11,17] IAS.SAV. 


STAGE 1 PROCEDURES 


14. Name the command file to be processed by phase 1 of system 
generation (SGN1). The command file can be any one of those 
provided with the system, e.g., RP@4L64K.CMD, or it can be a 
user created file. The following command to SGNI1 is used. 


SGN>@command file specification 
All of the commands read from the command file are printed on 
the terminal. Upon successful completion of the processing 
of the command file, the following message appears on _ the 
terminal. 

SGN>END OF PHASE 1 
Depress CTRL/C to obtain MCR. 


The host system remains usable in the normal way even if 
fatal errors occurred during execution of phase l. 


15. If any errors occurred during phase 1, correct them (consult 
Appendix E) and repeat steps 18 through 14. 


NOTE 


Fatal errors muSt be corrected, but 
diagnostic messages imply that the 
resulting system may be usable. 


16. Phase 1 of system generation does not produce a target system 
that is hardware bootable, i.e., it does not write physical 
block @ of the disk. 


STAGE 1 PROCEDURES 


6.2 PHASE 2 OF SYSTEM GENERATION 


Phase 1 of system generation has created a file on the target system 
disk. This file contains a memory image ready for phase 2. 


In this system, two tasks are active. One is the system disk handler, 
and the other is phase 2 of system generation. Bootstrapping this 
file into memory causes phase 2 to run. 


NOTE 


For phase 2 to execute successfully, it 
must be booted on a machine with as much 
or more memory than that specified 
during phase l. 


Phase 2 of system generation processes a command file named 
[11,17]SYSBLD.CMD. If any modifications need to be made to this file 
to reflect system requirements, they must be made by means of an 
editor prior to execution of phase 2 (see Chapter 2, section 2.1). 


The steps necessary to run phase 2 follow. 


1. Bootstrap phase 2. There are two ways to bootstrap phase 2 
into memory on the target system. Whichever way is used, it 
must be booted from the unit specified as SY during phase 1. 
Methods a and b follow. 


a. Create a bootstrap block @ on the target disk and use the 
hardware bootstrap. Issue the following command on_ the 
host system to create bootstrap block @. 


MCR>BOO target device: filename/WB 


filename is the name specified in the TARGET 
directive. 


This command takes virtual block 1 of the file created by 
phase 1 and writes it on physical block @ of the target 
device. The disk is now hardware bootable (see Section 
2.1). It can be taken to the target hardware and booted. 


b. Use the software BOOT function. The MCR software 
bootstrap function is described in Appendix D. The 
software bootstrap boots the file created by phase 1 into 
memory in the host system. Block @ of the target system 
is not modified. 


When the target system is bootstrapped there should be no 
other activity in the system. The host system is overlaid in 
memory by the target system. The host system remains 
unaltered. 


STAGE 1 PROCEDURES 


Before issuing the BOOT command, ensure that the target 
system disk is mounted on the unit specified as SY during 
phase 1. Then issue the following command to the host system. 


MCR>BOO target disk:filename 


Notice that the MCR BOOT command can be used to create the 
bootstrap block on a system disk by including the /WB switch 
or to perform the bootstrapping from any disk by omitting the 
/WB switch. The two functions are mutually exclusive. 


Once the system has been bootstrapped, phase 2 prints the 
following message. 


*** SYSTEM GENERATION PHASE 2 *** 


Phase 2 proceeds to mount the new system disk and then open 
and read the file SYSBLD.CMD. All commands encountered in 
SYSBLD.CMD are exeucted and echoed on the terminal. 


NOTE 


Loading handlers or fixing tasks in the 
partition in which SGN2 is- running 
results in fragmentation of that 
partition after SGN2 exits. 


Upon successful completion, phase 2 prints the following 
message. 


*** END OF SYSTEM GENERATION PHASE 2 *** 


Set the time and date, load the message output handler, and 
perform any other similar functions, e.g., loading other 
handlers. 


MCR>TIM hh:mm:ss dd-mmm-yy 
MCR>LOA MO 
MCR>LOA LP 


Pseudo devices such as the spooler (SP) and console listing 
device (CL) should be redirected to physical devices. For 
example: 


MCR>RED LP=CL 
MCR>RED SY=SP 


Any alterations to device characteristics can also be made. 
For example, the following command sets the line printer as a 
spooled device: 


MCR>SET /SP=LPQ@: 
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If satisfied at this point that the system generation was 
successful, dismount any mounted devices and perform a save 
using the MCR SAV command. The following is an example. 


MCR>DMO SY: 
MCR>SAV 


Once the system is saved, the following message is printed on 
the console. 


nnk IAS V@@1A nn is the memory size 
MCR> 


NOTE 


If at any time before performing the 
SAV, a reboot of the new system disk is 
performed, as described in step 1 above, 
phase 2 of system generation is executed 
again. 


A reboot after a SAV causes the same 
response as seen after performing the 
SAV above, i.e., nnk IAS V@@1A. 


If the user is satisfied with the system generation and wants 
the disk to be hardware bootable, the functions of step la in 
this section should be performed if they have not been done 
already. 


CHAPTER 7 


STAGE 2 PROCEDURES 


SGN2, the second phase of Stage 1 system generation installs the 
current version of the Timesharing Executive. Stage 2 enables the 
user to produce a new version of the the Timesharing Executive 
according to the installation’s requirements. Stage 2 may be 
performed at any time, independently of Stage l. 


1. The first step is to edit the file [311,197]SGDATA.MAC, 
which contains the interactive and batch parameters. These 
parameters are all described in Chapter 4. 


The following commands invoke the IAS Text Editor to edit 
[311,197] SGDATA.MAC: 


MCR>SET /UIC=[1,1] 

MCR>EDIT [311,197] SGDATA.MAC 
When each parameter has been set to the required value, the 
user then issues the commands described below. Most 
commands invoke indirect command files, thus simplifying the 
Stage 2 procedure. Appendix A lists the contents of the 
various command files. 
Note that user-written Command Language Interpreters (CLIs) 
that link with IASBUF must also be relinked, the old CLIs 
removed, and new ones installed in steps 3,4, and 5. Either 
issue individual commands in the appropriate place to do so 
or edit the command files to include the necessary commands. 


2. To assemble and build the IAS timesharing libraries, IASCOM 
and IASBUF: 


MCR>SET /UIC=[1,1] 
MCR>MAC @[311.197] MAC197 
MCR>TKB @[11,107] TKB197 


3. To relink all the tasks that use the libraries IASCOM and 
IASBUF: 


MCR>TKB @NEWTSTKB 


User-written CLIs should be relinked at this point. 
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4. The old tasks and libraries must then be removed from. the 
system. The libraries cannot be removed until all tasks 
which link to them have also been’ removed. Remove any 
user-writtem CLIs before issuing the following command. 

MCR>REM @OLDTSREM 
5. To install the new versions of the tasks and libraries: 
MCR>INS @NEWTSINS 
The libraries must be installed before the tasks. Do not 
install any user-written CLIs until the command file above 
has executed. 


6. TO save the system with the new Timesharing Executive and 
installed tasks: 


MCR>DMO system disk 
MCR>SAV 


A new version of the Timesharing Executive has now been built and 
saved into the system. 


APPENDIX A 
SYSTEM GENERATION FILES 


A.1 STAGE 1 FILES 
A.1.1 TT64PA.MAC 


me "6 ~s “se ~8 ~O TO TO ~SO WS WO ff 


=e =e 


me te MO NE TE TO NO 


SBTTL 


IAS fT64 TERMINAL HANDLER -- ASSEMBLY PARAMETERS 


THE FOLLOWING PARAMETERS ARE USED AT ASSEMBLY TIME TO 
DEFINE THE NUMBER AND TYPE OF TERMINAL INTERFACES 
IN THE SYSTEM. 


IF THE TERMINAL CONFIGURATION IS CHANGED THE PARAMETERS 
MUST BE CHANGED ACCORDINGLY AND THE HANDLER RE-ASSEMBLED 
AND RE-LINKED. 


TTYNUM = 1. > THE TOTAL NUMBER OF TERMINAL INTERFACES 

; IN THE SYSTEM. 
DHUN = Q ; THE NUMBER OF DH11 (AND DM11-BB) (16-LINE) UNITS. 
DJUN = Q + THE NUMBER OF DJ11 (16-LINE) UNITS. 
DCUN = Q ; THE NUMBER OF DCll (SINGLE LINE) UNITS. 
DLII1E = 9 ; THE NUMBER OF DLI1E (SINGLE LINE) UNITS. 
DMEPA = ; THE EXTERNAL PAGE ADDRESS OF THE DM11-BB UNIT 

; ATTACHED TO THE FIRST DH11; 96 IF NON-EXISTENT. 

+ THE SECOND DH11 IS ASSIGNED THE DMl1 AT DMEPA+1@ ETC. 
DIAL = Q ; NON-ZERO IF DIAL-UP LINES NEED SERVICEING. 
PGEN = Q ; NON-ZERO IF ANY OF THE DL11 TERMINALS NEED PARITY. 
SECOND = 3. ; MODEM (DL11E,DM11BB) INSPECTION TIME INTERVAL 
TMUNIT = 2 $e ee eee eee ~-- RATE 


THE REMAINDER OF THE IAS TT64 TERMINAL HANDLER 
CODE FOLLOWS IN ISTT64.MAC 


A.1.2 RPO4L64K.CMD 


[ll,1 7] RP@4tL64Kk.CMD 


s =e we 


PDP11=45,64K 


SCOM=,349,96 
PAR=SYSDSK, ,61,U 
PAR=SYS,,114,T 
PAR=FILE, ,121,U 
PAR=TTY, ,132,U 
PAR=GEN, ,2400,T 


/ 

DEV=DK@ ,RKO5,220,5,177400 
DEV=DK1,RK05,220,5,177400 
DEV=DB@ ,RP@4,254,5,175708 
DEV=TTY ,LA30S,60,4,177568 
DEV=LP¢,LP11B,290,4,177514 
DEV=DT@ ,DT11,214,6,177348 
DEV=DT1 ,0T11,214,6,177349 
DEV=MT@ ,TU19,224,5,172529 
DEV=MM9 ,TU16,224,5,172449 
DEV=MO, 77,4 

DEV=SP ,<190000,0,0,0>,,, 
DEV=PI,77,% 

DEV=TO,,7, 


y 

DPAR=GEN 
CKPNT=DBQ , 50K 
SY=DBQ 


if 

INS=SYSDSK,[11,1]DB 

INS=GEN, [11,17] SGN2, [11,1] ISMOU, [11,17] INZ/UIC=[1,1] 
INS=FILE, [11,1] ISFCP 

INS=TTY, [11,1] ISTT64 

// 


A.1.3 SYSBLD.CMD 


Poles be 1S YS Be oD, CMe 


INPUT FILE TO SYSGEN PHASE 2. ANY MCR FUNCTION IS. ALLOWED 
EXCEPT SAV AND BOO. CARE MUST BE TAKEN THAT ANY TASK 
REQUIRED BY SG2 HAS BEEN INSTALLED BEFORE SG2 TRIES TO 
USE IT. 


=e =e TS SO MO Ne MO NS NO 


INZ [11,1]MCR 

INZ SYSRES/LI/ACC=RO/UIC=[1,1] 
* DELAY 

INZ [11,1] INS 

* DELAY 

INS [11,1] FIX 

* DELAY 

FIX F11ACP 

* DELAY 


INS IASCOM/LI/ACC=RO/UIC=[1,1] 
INS IASBUF/LI/ACC=RO/UIC=[1,1] 
INS PDSLIB/LI/ACC=RO/UIC= [1,1] 
* DELAY 

INS [11,1]ISDT 
INS [11,1]DK 

INS [11,1] LP 

INS [11,1] MO 

INS [11,1] ISTU16 
INS [11,1] QUE 
INS [11,1] ISSPR 
INS [11,1]SPR2 
INS [11,1] ISOPR 
INS [11,1] TKTN 
INS [11,1] ABO 
INS [11,1]ACT 
INS [11,1]ALT 
INS [11,1] BOO 
INS [11,1]COM 
INS [11,1] ISDEV 
INS [11,1] ISDMO 
INS [11,1]EDI 
INS [11,1] FLX 
INS [11,1] F11MSG 
INS [11,1] INI 
INS [11,1] LOA 
INS [11,1] LUN 
INS [11,1] PURMAC 
INS [11,1]OPE 
INS [11,1] PAR 
INS [11,1] PURPIP 
INS [11,1]REA 
INS [11,1] ISRED 
INS [11,1] REM 
INS [11,1] RUN 
INS [11,1]SAV 
INS [11,1]SET 
INS [11,1]SLpP 
INS [l11,1]TAS 
INS [11,1]TIM 
INS [11,1] UFD 
INS [11,1] UNF 
INS [11,1] UNL 
INS [11,1] USERS 
INS [11,1]ACCOUNTS 
INS [11,1] VFyY 
INS [11,1]SCI 
INS [11,1] IAS 
INS [11,1] IASTART 
INS [11,1]TCP 
INS [11,1]TSS1 
INS [11,1] TSS3 
INS [11,1] TSSNUL 
INS [11,1]TKB 
INS [11,1] DMP 
INS [11,1] LBR 

* DELAY 

REM ...INZ 

* DELAY 

* DELAY 


A.2 STAGE 2 FILE 


A.2.1 SGDATA.MAC 


SBTTL EQUATES FOR VARIABLE PARAMETERS 


VARIABLE PARAMETERS 


THESE PARAMETERS HAVE INITIAL VALUES DEFAULTED TO 

, THEM BELOW. 

THOSE PREFIXED ‘SG’ MAY BE CHANGED DIRECTLY OR 

INDIRECTLY BY USER SPECIFICATION AT SYSGEN TIME. 

SGLUN = 6. ;MAX NO. OF LUNS FOR 1 JOB 

ScuvL = 6. ;MAX NUMBER OF DEVICES ALLOCATABLE BY A USER 
SGDEV = 8. ;NO. OF NON-TERMINAL DEVICES USED BY TIMESHARING 
SGTMM = 6. ;MAX NO. OF TERMINALS 

ScATT = 6. ;MAX NO. OF ACTIVE TERMINALS AT ANY TIME 
SGXTSK = 6. ;NO. OF TASKS OVER ‘1 PER TERMINAL’ (IE. NON CLI TASKS) 
SGXBF = SGATT+SGXTSK+1] ; NO. OF BUFFERS 

ScTKSz = 1024. ; MAX TASK SWAP SIZE(32 WORD BLOCKS) 

SGBUF = 80. ;SIZE OF TERMINAL BUFFER (BYTES) 

SGCIT = 3. ;NO.OF CLI’S WHICH CAN RUN CONCURRENTLY 
SGUTL = 4. ;NO. OF SCHEDULING LEVELS | 

H 

SGSPR = 2500 ; TICKS BETWEEN SCHEDULER PROMOTIONS 

ScstK = 1 ; SIZE OF SYSTEM IDLE TIME 

SGCON = 2. ; CONSTANT IN QUANTUM EQUATION 

SGTSL = 25. ; TIME SLICE MAXIMUM SIZE 

SGAFM = 24 ; ALLOCATION FACTOR MEMORY SIZE 

SGAFT = 1 ; ALLOCATION FACTOR TICKS/MEMORY SIZE 

SGBSH = 6000. ; TIME BETWEEN BATCH SCHEDULES 

SGBOT = SGTSL BATCH QUANTUM 


NO WHEN THIS PARAMETER IS NON ZERO A BATCH 
SCHEDULING LEVEL (BOTTOM LEVEL) IS AUTOMATICALLY CREATED 


=e =e Ne 


SGBISP 
SGT1PR 


SGPIPR 


° 
’ 


; 
SGSPF 
SGLBSZ 


; 
SGFLSZ 


id 


Q 
100. 


SGT1PR+t1 


500. 


=e 


=e 


~e 


=e 


=e 


me 


MAX NON-SWAPPABLE SPACE (MOD 32 WORDS) 
TSS1 PRIORITY 


TCP PRIORITY 


NUMBER OF SWAP FILES 
LOGICAL SWAP BLOCK SIZE (NUMBER OF 256. 


MAX LOGICAL BLOCKS PER SWAP FILE 


WORD BLOCKS) 


=e =e te te me Me TE MO Ne NO Ne M8 NO MO MO NS Ne ~O8 M8 TO MS TO NO NSH TO NO MO MO TE Ne NS TE TO TO 


APPENDIX B 


DEVICE CHARACTERISTICS WORDS 


-SBITL DVSCH -- THE DEVICE CHARACTERISTICS MACRO 


MACRO TO GENERATE AN ENTRY IN THE DEVICE CHARACTERISTICS 
TABLE. 


MACRO FORMAT: 


DEVCH NAME ,AC1 ,AC2,AC3,AC4,ACP,BNAM, BLKCNV ,VSIZH,VSIZL 


WHERE: NAME = DEVICE NAME STORED AS TW@ RAD5@ 
WORDS. 
AC1l = PUD CHARACTERISTICS WORD 1 (DEV. INDEP.) 
AC2 = i " ys (DEV. DEPEN.) 
AC3 = . . 3 (DEV. DEPEN.) 
AC4 = " : 4. (TXFR. SIZE) 


(FOR DEFINITION OF THE ABOVE, SEE EXECUTIVE AND APPROPRIATE 
DEVICE HANDLER) 


ACP 
BNAM 


DEFAULT ACP FOR THIS DEVICE 
FOUR ASCII CHARACTERS WHICH 
IDENTIFY THE BOOTSTRAP 
PROGRAM. 
(2 ZERO WORDS FOR NON-BOOTABLE 
DEVICES) 
ADDRESS OF CONVERSION ROUTINE 
WITHIN MODULE CRBOT TO 
CONVERT FCS BLOCK NO. TO 
PHYSICAL DISK ADDRESS 
(ZERO FOR NON-BOOTABLE DEVICES) 
HIGH ORDER PART OF VOLUME SIZE 
FOR DIRECTORY DEVICES. 
(ZERO FOR OTHERS) 
LOW ORDER VOL. SIZE 


BLKCNV 


VSIZH 


VSIZL 


»-MACRO DEVCH ANAME ,AC1 ,AC2 ,AC3,AC4,ACP,BNAM, BLKCNV,VSIZH,VSIZL,?2 
»-RAD5@ /ANAME/ 


- WORD AC1l 
- WO RD AC2 
- WORD AC3 
- WORD AC4 


-IIF NB <ACP> ~-RAD5@ /ACP/ 
-TIF B <ACP> - WORD @ 
-IIF NB <BNAM> -ASCII /BNAM/ 
-TIF B <BNAM> - BLKW 2 
-lIF NB <BLKCNV> - WORD BLKCNV 


DCHEN: 


-SBTTL 


B <BLKCNV> - WORD 4) 


NB <VSIZH> - WORD VSIZH 
B <VSIZH> - WORD 4) 
NB <VSIZL> - WORD VSIZL 
B <VSIZL> - WORD Y) 


»>LENGTH OF CHARACTERISTICS TABLE 


DVSCH -- STANDARD SUPPORTED DEVICE CHARACTERISTICS 


DEFINE THE DEVICE CHARACTERISTICS TABLE 


DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 


_ DEVCH 


DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 
DEVCH 


LA30P,7,0,1,72. 

LA30S,7,20000,1,72. 

LA36,7,210080,1,132. 

VTO5,7,50010,0,80. 

KSR33,7,4000,0,72. 

PTR,40,0,8,1000 

PTP ,40,9,9,190098 
RK@3,140019,503,0,512.,F11,RK05,RKO5DA, ,4800. 
LP11A,3,0,0,80. 

LP11B,3,9,80,132. 
DT11,140019,0,0,512.,F11l,,,,578. 
AFC11,0,1823.,9,0 

ADO1 pa) ,100,@ a) 

LPS11,0,16.,0,0 

UDE11,0,0,9,20 
RKO5,140010,503,0,512.,F11,RK@5,RKO5DA, ,4800. 
RP@2,1408019,49000,0,512.,F11,RP03,RP23AB, ,40000. 
RP#3A,140010,160000,0,512.,F11,RP83,RP23AB,1,34200 
RP93B,148010,140000,0,512.,F11,RP03,RP23AB,1,34200 
KSR35,7,2000,0,72. 
RF1,149010,0,0,512.,F11,RF11,RFDSK,,19024. 
RF2,140019,0,0,512.,F11,RF11,RFDSK,,29048. 

RF3 ,140010,8,0,512.,F11,RF11,RFDSK,,39072. 
RF4,140010,0,0,512.,F11,RF11,RFDSK,,4096. 
RF5,146010,0,9,512.,F11,RF11,RFDSK,,5120. 
RF6,140010,0,0,512.,F11,RF11,RFDSK,,6144. 
RF7,148010,0,90,512.,F1l1,RF11,RFDSK,,7168. 
RF8,140010,0,0,512.,F11,RF11,RFDSK,,8192. 
CR11,1,0,0,80. 
RPO4,140018,160000,0,512.,F11,RP04,RP@4DA,2,117426 
RS83,148018,190000,0,512.,F11,RS04,RS03DA, ,1024. 
RSO4,140010,140090,0,512.,F11,RS94,RS@4DA, ,2048. 
TU1@,140079,0,8,512.,MTA 
TU16,140078,100000,0,512.,MTA 
TA11,100070,0,0,128. 

,9,9,0,8 


APPENDIX C 


SYSTEM GENERATION FOR TERMINALS ON DH11 OR DJ11 LINES 


Normally during system generation, when a device is defined using the 
DEV directive, the type parameter in the DEV directive supplies the 
information needed by the system to fill in the four device 
characteristics words of the PUD. However, in certain cases, the user 
must supply the information for the characteristics words in a 
different format. Such is the case for terminals connected to DH1l or 
DJ11 lines. The format of the DEV directive used to provide this 
information follows. 


DEV=dev,<charl,char2,char3,char4>,trap,pri,ext-page[,devacp] 


All parameters, except those for the characteristics words, are 
identical with those described in Chapter 3 of this manual. 


charl = characteristics word 1. It has the following values. 
Word Bit Meaning If Set (Bit=1) 
1 g Indicates a record-oriented device, e.g.,card 
reader. , 
1 Indicates a carriage control device, e.g., 
line printer. 
2 Indicates a terminal device, e.g.,LA3Q@. 
3 Indicates a multiple directory device. 
4 Indicates a single directory device. 
5 Indicates a sequential device, e.g., magnetic 
tape. 
6 Indicates an output spooled device. 
char2 = characteristics word 2. It contains device-specific 
flags used by the handler. See Table C-l. 
char3 = characteristics word 3. It contains additional flags 
used by the handler. See Table C-2. 
char4 = characteristics word 4. It contains the maximum block 


(buffer) size for the device as an octal number of 
bytes. 


TERMINALS ON DH11 OR DJ1l LINES 


(C.1 PUD CHARACTERISTICS WORDS 


For DL, lines, the type parameter may be used in the DEV directive 
instead of explicitly stating the individual characteristics words. 


Table C-4 contains examples of the four characteristics words for some 
terminals devices connected to DHl1 lines. 


Table C-5 contains the four characteristics words for all supported 
terminals device connected to DJll lines. 


Table C-1 
Characteristics Word 2 for Terminal Handler 


Meaning if Set 


Carriage control type 
g KSR33, KSR35, LA3@P 
1 LA3@S 
2 VTO5 


Scope (enables VT@5 to run at speeds up to 
2408 baud) 


ALT code 175 


ALT code 176 

Lower case enabled 

Parity exists 

Odd parity 

DH11 Interface for this terminal 
Hardware form feed 

Hardware vertical tab 

Hardware horizontal tab 

Local echo 


No printer 


No keyboard 


TERMINALS ON DH11 OR DJ11 LINES 


Table cC-2 
Characteristics Word 3 for Terminal Handler 


Meaning if Set 

DLII1E interface for this terminal 
Indicates DM11-BB Controller 
Transmitter speed 

See Table C-3. 
Receiver speed 
Must be @ 
DJ11 Interface for this terminal 
Dial-up line 
DCll interface for this terminal 


EIA interface (for DH only) 


Margin (LA3@ only) 
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Receiver re Cer ee a iranent tier Speeds 


\o 
©O 
~ 
OV 


Zero Baud 
5@ Baud 
75 Baud 
11@ Baud 
134.5 Baud 
15@ Baud 
200 Baud 
388 Baud 
609 Baud 
1208 Baud 
1808 Baud 
2488 Baud 
4888 Baud 
96098 Baud 


HEHE rPHEHEeRAReeaans 
KHPrEeOOOFPrRHEF RSA 
MOrPrPABSEERBRH-EHAS 
MPOarPOArPREFOFEFaAFSaAESD 


Table C-4 
Characteristics Words for Devices on DH1l Lines 


VT@5 on dial-up line (11@ baud send/ <7,50118,46312,120> 
receive with DM11-BB) 


VT@5 on local DH line (15@ receive/ <7,58118,665080,120> 
2488 send) where the DM11-BB is 
attached to DH1l unit 


VTO5 on local DH line (11@ baud) <7,50110,26508,120> 
2408 send) with no DM11-BB 


KSR33 on local DH line (110 baud) <7,61908,46308,119> 
with DM11-BB 


LA3®@S on local DH line (3008 baud) <7,201080,56701,120> 
with DM11-BB 


If any DH lines are connected to the 
DM11-BB, all lines for the DH unit must 
be connected. 
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Table C-5 _. : 
Characteristics Words for Devices on DJ Lines 


Device Characteristics Word 
VT@5 on DJ line <7,580018,20,129> 
KSR33 or KSR35 on DJ line <7,6000,20,119> 
LA3@S on DJ line <7,280008,21,129> 


LA3@P on DJ line <7,0,21,120> 


C.2 PARTITION 


The size of the TTY partion must be large enough for the size of the 
handler. When the TTY partition is enlarged, some other partition 
(e.g. GEN) must be decreased accordingly. 


C.3 LOGICAL NAMES AND NUMBERS 


IAS terminals have device names in the format TT@,TTl,..., TTn; n is 
the octal unit number. A DH11 or DJ11 hardware unit multiplexes 16 
lines. The lines are distinguished by subline numbers. 


At initialization, the Teletype handler must establish a 
correspondence between each hardware number and the corresponding PUD 
unit number. The handler also must allow for the possible existence 
of gaps in the hardware numbers for the DHI1l. 


C.3.1 EIA and 20 ma Lines (DH11 only) 


Generally, four line adaptor units are connected to a DH11. Each of 
these units performs line adaption for four terminal lines. 


C.3.2 How to Assign Names 


The terminal unit numbers are assigned to DH11 subline numbers in 
Order. The only exception is that there can be a gap between the EIA 
lines, which must come first, and the 28 ma lines. If a gap occurs, 
the DH11 subline number is assumed to jump to the next group of four 
lines. The following is an example. 


IF: TT7 is the first Teletype PUD to indicate that it is 
connected to a DHI11 unit. The PUD characteristics 
words also indicate that it is an EIA line. 


AND: TT1@ is connected to the same DH11 unit, but the PUD 
characteristics words indicate that the line adaptor is 
a 2@ ma connection. 
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THEN: TT7 is assigned to DH subline number @ and TT1@ is 
assigned to DH subline number 4. 
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MCR COMMANDS 


This appendix describes some MCR commands’ used during system 
generation. The commands described are: 


BOOT 

DISMOUNT 

FIX- IN-MEMORY 
INITIALIZE VOLUME © 
INSTALL TASK 

LIST COMMON BLOCKS 
LOAD 

MOUNT 

PARTITIONS 
REDIRECT 

SAVE 

SET 

TIME 

UNFIX 

UNLOAD 

USER FILE DIRECTORY 
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BOO 


D.1 BOOTSTRAP COMMAND (BOO) 


FUNCTION 
The BOOTSTRAP command (BOO) allows the user to perform either of the 


following mutually exclusive operations: 


Lie Stop the present system and bootstrap another system from any 
system device. 


2s Copy a bootstrap block on to block @ of the specified device 
from a specified IAS system image file on the same device. 


FORMAT 
The BOOT command can be specified in four different formats. Each 
format is discussed separately. 
Format 1 
BOO[T] CR 
When this format is used, BOOT issues the following prompt: 
BOO> 


The user must now enter another carriage return. 


When executed in this format the BOOT command causes the latest 
version of the file IAS.SAV (residing in the default directory file of 
the system disk) to be bootstrapped into memory. 


Format 2 


BOO[T] filespec 
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where: 


filespec is the file specification of the file that contains, as 
its first record, the bootstrap routine to be used in 
re-bootstrapping the operating system. Table D-1 
contains a list of default values for BOOT file 
specifications. 


When this format is used, the BOOT command causes the bootstrap 
routine to be loaded from the file specified by "filespec". This 
bootstrap routine then loads the remainder of the file into memory 
thus starting up the new IAS system. 


Format 3 
BOO[T] /WB 
where: 
/WB is the write bootstrap switch. 


When this format is used, a bootstrap routine is written on block @ of 
the system device. The bootstrap routine is copied from virtual block 
one of the latest version of file IAS.SAV residing in the default 
directory file on the system device. 


Format 
BOO[T] filespec/WB 


where: 


filespec is the file specification of the file that contains, as 
its first virtual block, the bootstrap routine to be 
used. Table D-1l contains a list of default values’ for 
BOOT file specifications. 


When this format is used, the bootstrap routine which is contained as 
the first virtual block in the specified file is copied out to block @ 
of the specified device. 
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Table D-1l 
Defaults In BOO File Specifications 


Specification] Default 


dev: 


ufd 


SY: 


The UFD which corresponds to the current UIC under 
which the user is running 


filename IAS 


extension -SAV 


sversion Highest version 


TECHNICAL NOTES 


iss 


EXAMPLES: 


‘Ls 


All devices, except the one from which the bootstrap 
operation is to be accomplished, should be dismounted. 


When a re-bootstrap is to take place, no tasks should be 
running on the current system. 


The device from which a task is installed is recorded in that 
task’s STD entry. Therefore, after bootstrapping a new 
system, any installed tasks must be present at the same place 
on their original devices; e.g. ,a System pack cannot be 
moved from DK% to DKl and then bootstrapped using the BOOT 
command. 


Only as much memory as was specified at system generation 
time will be loaded during the bootstrap operation. 


The file specified to BOO must have been created by system 
generation and must not have been removed or copied after 
creation, 


MCR>BOO CR 


In this example, the system is re-bootstrapped using the 
latest version of the system image file IAS.SAV (which 
resides in the default directory file on device SY:). 


MCR>BOO DK1: [19,19] SYS.SAV 
In this example, the system is re-bootstrapped using the 


latest version of the system image file SYS.SAV (which 
resides in directory file [18,180] on device DKl:). 
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MCR>BOO /WB 


In this example, a bootstrap routine is copied from virtual 
block one of the system image file IAS.SAV (which resides in 
the default directory file on SY:) to block @ of device SyY:. 


MCR>BOO DK1: [19,19] SYS.SAV/WB 
In this example, a bootstrap routine is copied, from virtual 


block one of the system image file SYS.SAV (which resides in 
directory file [19,18]. on DKl:) to block @'of device DKl:. 
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D.2 DISMOUNT VOLUME COMMAND (DMO) 


FUNCTION 

The Dismount Volume (DMO) command logically dismounts (makes invisible 
to the system) a previously mounted volume. DMO deletes the Volume 
Control block (VCB) and its extensions, thus declaring the volume to 
be logically off-line, and rendering it inaccessible. 


If the volume contains files currently being accessed, the following 
message is issued, and the dismount operation is aborted: 


DMO -- VOLUME BUSY. TRY AGAIN LATER 


FORMAT 


DMO dev: [volumelabel] [/UIC=[uic] ] [/LOCK] 


where: 

dev: is the device specification for the device on which 
the volume is mounted. 

volumelabel is the label of the volume being dismounted. If 
specified, the value entered is compared with the 
corresponding value in the VCB. If they are not the 
same, the volume is not dismounted. 

/UIC=[uic] is the Volume UIC. Like the volume label, it is 
compared to its corresponding entry in the VCB. If 
unegual, the volume is not dismounted. 

/ LOCK If this option is specified, the volume is marked 


for dismount regardless of whether files are 
currently accessed on it. Further accesses are then 
disallowed and the volume is actually dismounted 
only when all current file accesses are terminated. 


If the DMO command is issued for any volume of a multi-volume magnetic 
tape file, all of the mounted volumes are automatically dismounted. 


The following message is issued by the file processor when the logical 
dismount is completed and it is safe physically to remove the volume 
from the system: 


DMO -- DK@: ** DISMOUNT COMPLETE ** 


EXAMPLES 


l. 
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MCR>DMO DK1: 


In this example, the VCB for the volume mounted on DK1: is 
deleted, and the volume becomes inaccessible. 


MCR>DMO DK1:RICKSVOL/UIC= [309,399] 


In this example, the VCB for the volume mounted on DKl: is 
interrogated. If it contains a volume label of "RICKSVOL" 
and a UIC of "[{300,300]", the VCB is deleted,, and the volume 
becomes inaccessible; otherwise, the volume remains mounted. 
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FIX 


D.3 FIX-IN-MEMORY COMMAND (FIX) 


FUNCTION 
The FIX-IN-MEMORY command (FIX) allows a task to be fixed in its 
default partition; i.e., to dedicate memory to a task for faster 


response to requests for execution. A task cannot be fixed unless it 
was built as a fixable task. 


FORMAT 


FIX taskname[/TI=dev][,taskname[/TI=dev],...] 


where: 
taskname is the name of the task being fixed in memory. 
/Til=dev is an optional switch which specifies the TI under 
which the task is to be fixed. dev is the device 
mnemonic for the terminal corresponding to the TI 
under which the task is to run. 
EXAMPLES 


1. MCR>FIX XKE 
2. MCR>FIX JAG,2402 


In the examples above, the tasks XKE, JAG, and 24@Z are fixed 
in their default partitions. 


MCR COMMANDS 


D.4 INITIALIZE VOLUME COMMAND (INI) 
FUNCTION 


WARNING 


Any data stored on the volume will be 
destroyed when INI is executed. 


The INITIALIZE VOLUME command (INI) provides the user with a_ facility 
for producing new Files-1ll structured volumes. Files-1ll structured 
volumes are discussed in detail in the IAS/RSX-11 I/O Operations 
Reference Manual. 
FORMAT 

INI[TVOL] dev: [volumelabel] [/keyword(s) ] 


where: 


dev: is the device specification of any file structured 
media. 


volumelabel is the label being assigned to the volume. 


NOTE 
Volume labels can be from 1 to 12 
alphanumeric characters in length. 
The only exception is magnetic tape 


volumes which are from 1 to 6 
alphanumeric characters in length. 


/keyword(s) define the volume characteristics. If no keywords 
are specified, the default characteristics are 
used (see individual keyword descriptions). The 
following keyword options are provided. 
/UIC=[group number, member number] 

Default 
/UIC=[1,1] 
/PRO=[system,owner,group,world] 
This keyword allows the user to establish volume 


access privileges. Each entry consists of from 
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one to four letters which have the _ following 
meanings: 

R - for READ access 

W - for WRITE access 

E - for EXTEND access 

D — for DELETE access 
The absence of a code letter means the access 
right is denied to the user. 
Protection code subparameters (system, 
owner, group, world) are positional; therefore, 
the location of the entry in the parameter string 
defines the user to whom the codes apply. 
Example 

/PRO= [RWED,RWED,RW,RW] 


In this example, group and world are denied extend 
and delete access. 


Default 


/PRO= [RWED,RWED,RWED,RWED] 


NOTES 
l. On magnetic tape, the 
protection option delete is 
equivalent to write, since 
write access implies’ total 
access because of the 
sequential nature of magnetic 


tape. 


2% Extend access may be specified 
without write access. This 
implies that the user may 
extend the last file on the 
volume, but not write on the 
volume in any other manner. 


/MXF=maximum number of files allowed on this 
volume. The highest maximum permitted is one 
half the number of blocks on the volume or 
65535 decimal, whichever is less. 


Example 
/MXF=10 
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Default 


One fourth the number of blocks on the 
volume. 


/EXT=default file extension size in blocks. 
Default 
/EXT=5 
/FPRO=[default file protection] 


This parameter is entered using the same 
format as the /PRO keyword. 


Default 
/FPRO=[RWED,RWED,RWE,R] 
/CHA=[characteristic words] 
This keyword defines the device 


characteristics. The possible parameters for 
this keyword follow: 


ATCH - device may be attached for 
exclusive use by one task. 

DCF -~ device control functions 
permitted; Read/Write 


logical, for example. 
Example 
/CHA= [ATCH, DCF] 
Default 
No ATCH and no DCF 


/INF=number of file headers to allocate in the 
initial index file. 


Default 
/ INF=16 
/WIN=default window size for file access to this 
volume. Represents the number of retrieval 
pointers. 
Default 
/WIN=7 
/LRU=number of directories to keep pre-accessed 


while volume is in use. For optimized 
directory access this value should be 
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slightly higher than the expected number of 
concurrent users of the volume. 
Default 

/LRU=3 

/INDX=Option - Index file position. 

Options are: 
BEG - beginning of volume 
MID - middle of volume 
END - end of volume 
BLK:number - logical block number 
Example 


/ INDX=BLK:190 


Default 
/ INDX=MID 
/BAD=[options] - Initialize bad block file. 


Options are: 


AUTO —- use bad blocks data left on volume by 
BAD command. 


MAN -—- enter bad blocks. 


If both options are used, they must be 
separated by a comma. 


Example 

/ BAD= [AUTO] 
or 
/ BAD= [{ AUTO, MAN] 
Default 


None 
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D.4.1 MAN Option for /BAD keyword 


When "MAN" is specified as the /BAD keyword option, INI will issue the 
following prompt: 


INI>BAD= 


This prompt is issued after the INI command line is terminated, and 
before INI begins processing (initializing) the requested volume. 


After INI issues the prompt, the user can begin entering bad block 
location data. Bad block data is entered immediately following the 
equal sign (=) in the following format. 


INI>BAD=vu[ ,n] 


wheres: 

u is the logical block number, in octal, of the initial 
bad block in the group. 

n is the number, in octal, of consecutive blocks 
contained in the group. If omitted, a value of one is 
assumed. 

NOTE 


If a decimal number is used for either u 
of n, it must be followed by a decimal 
point (.). 


After the first group of bad blocks is entered, INI reissues’ the 


prompt. The user can, if necessary, enter more bad block data by 
simply repeating the above procedure. 


To terminate, the user need only enter a carriage return immediately 
following the equal sign (=) without entering data. 


Upon termination, the initial INI command line, including the bad 
block data, iS processed, and the requested volume is initialized.-: 
TECHNICAL NOTES 

Because of the large number of options available with the INI command, 
it may not be possible to enter the entire command string on a single 
line. For this reason, INI can to accept multiline commands. To 
accomplish this, the user must follow the procedure outlined below. 

1. INI must be initiated as follows: 


MCR>INI CR 


When INI is ready to accept command lines, the following 
prompt is issued. 


INI> 


EXAMPLES 


1. 
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At this point, multiple lines can be typed in to INI. Each 
line except the last must contain a hyphen (-) as the last 
character entered. When INI recognizes the hyphen, it 
assumes that the command line is incomplete, and reissues the 
INI> prompt for more parameters. When the last line is 
entered (nohyphens), INI begins processing the command. 


MCR>INI DB1:TESTPACK/CHA= [ATCH, DCF] /BAD= [AUTO] 


In this example, a disk volume on DBl: is initialized with 
the following characteristics: 


Volume label - TESTPACK 

UIC = [Lt] 

Volume Protection - System = RWED 
Owner = RWED 
Group = RWED 
World = RWED 

Maximum number of - 42949 

files 

Default file extension - 5 

File protection - System = RWED 
Owner = RWED 
Group = RWE 
World = R 

Characteristic word - ATCH and DCF 

Index file position - MID 

Bad blocks - Automatically accounted for. 

Number of headers in - 16 

index file 

Window size - 7 

Number of pre-accessed - 3 


directories 
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MCR>INI DB1: TESTPACK/PRO= [RWED,RWED,RW,R] /CHA=[ATCH, DCF] - 
/BAD= [MAN] 
INI>BAD=6.,19. 
INI>BAD=12. 
INI>BAD= 


In the above example, a disk volume on DBl: is initialized 
with the following characteristics: 


Volume label - TESTPACK 

UIC =< [Lyi] 

Volume protection - System = RWED 
Owner = RWED 
Group = RW 
World = R 


Maximum number of files- 42949. 


Default file extension - 5 

File protection - System = RWED 
Owner = RWED 
Group = RWE 
World = R 

Characteristic word - ATCH and DCF 

Index file position - MID 

Bad blocks - 6 through 17, and 12 

Number of headers - 16 

in index file 

Window size -~ 7 

Number of pre-accessed - 3 


directories 


MCR COMMANDS 


INS 


D.5 INSTALL TASK COMMAND (INS) 
FUNCTION 


The INSTALL TASK command (INS) installs tasks and shareable global 
areas (SGAsS) in the system. It can also override or extend some of 
the attributes assigned to the task by the Task Builder. These 
Overrides are specified in the form of keyword parameters appended to 
the task image file specification(s) in the INS command line. 
FORMAT 

INS{[TALL] filespec[/keyword(s) ] [,filespec[/keyword(s)],...)] 
or 

INS[TALL] @indirect 


where: 


filespec is the file specification for the image (task or 
shareable global area) being installed. Table D-2 
contains a list of defaults in INS file 
specifications. 

/ keyword(s) Option parameter(s) used to override or extend > 
arguments assigned at task-build time. The 
following keyword options are provided: 
/PAR=partition name 

This option specifies the partition into 
which the task or global area is to be 
installed. 
Example 

/ PAR=GEN 
Default 

Value specified at system generation. 

/PRIi=priority-number (decimal) 

This option specifies the execution priority 
to be assigned to the task. Priority ranges 
from a low of 1 to a high of 259. 


Example 


/PRI=266 
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Default 
/PRI=59@ 


/TASK=taskname 


This option allows the user to assign a name 
to the task or SGA being installed. Task 
names can be from 1 to 6 alphanumeric 


characters in length. 
Example 
/TASK=RICK 


/POOL=pool-limit (decimal) 


This option allows the user to assign a new 


pool limit to the task being installed. 


The pool limit value can be from 9% to 


255 


decimal, and represents the maximum number of 


8-word nodes that the task is allowed to 
at one time. 


Example 
/POOL=19@ 


Default 


use 


/POOL=4% (established by task builder) 


/UIC=[uic] 


This option allows the user to change the 


task°s UIC, or the owning UIC of an SGA. 
Example 


/UIC=[11,11] 


/ACC=non-owner access expressed as RO, RW, or 


This switch allows the user to specify 
access privileges afforded non-owners 
specified SGA. A non-owner of a SGA is 


NA 


the 
of a 
one 


whose UIC does not exactly match that of the 


SGA. RO, RW, and NA equate to read 
write only, no access, respectively. 


Example 
/ACC=RO 


Default 
/ACC=NA 
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/LI and /CM 
These options are used to specify that the 
entity being installed is either a library 
(/LI) or a common area (/CM). 
Default 


/CM 


Table D-2 
Defaults in INS File Specifications 


Default 


If omitted in the first or only file 
specification, SY: is used. 


If omitted in the second through n file 
specifications, the device specified or defaulted 
from the previous file specification is used. 

[ufd] If omitted in a file specification, the UFD that 
corresponds to the UIC under which the user is 
running. 


filename Must be specified. 


extension -TSK 


;ver The highest version for the file. 


EXAMPLES: 
1. MCR>INS SCAN 


In this example, the latest version of the task image file 
SCAN.TSK is selected, and the task image which it contains is 
installed. None of the task attributes that were assigned to 
the task at task-build time are changed. 


2. MCR>INS DB1: [11,2] SCAN; 3/PRI=103,RICK/TASK=HELP 


In this example, the tasks to be installed reside in 
directory file [11,2] on DBl:. Version 3 of task image file 
SCAN.TSK, and the latest version of task image file RICK.TSK 
are selected. The task images contained in these files are 
installed into the system, with the following modifications 
being made to them. Task image SCAN will have its priority 
changed to 183, and task image RICK will have its name 
changed to "HELP". 
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D.6 LIST COMMON BLOCKS COMMAND (COM) 


FUNCTION 
The COMMON BLOCKS (COM) command lists on the user terminal a 


description of each installed shareable global area (i.e., dynamic 
libraries and common blocks). 


FORMAT 


COM[MON BLOCKS] 


EXAMPLE 
MCR>COMMON BLOCKS 


SYSRES 290400 916200 1,1 RO LIB PI 82/04/75 


Figure D-l describes the information listed by the COMMON BLOCKS 
command. 


1 2 3 4 5 6 
SYSRES 200400 916200 1.1 RO LIB PI 92/64/75 


1. Common Blocks name, Common Block baSe and Common Block size 
with numeric values in octal notation 


2. UIC 


3. Non-owner access (NA = no access, RO = read only, RW = 
read/write) 


4. Gibrary or Common Block indicator (i.e., LIB or COM) 


5. Position Independent Code indicator (i.e. PI or blank) 


Date of Library or Common Block creation in the form mm/dd/yy 


Figure D-1 
Sample COMMON BLOCK Listing and 
Description of Listed Items 
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D.7 LOAD COMMAND (LOA) 


FUNCTION 
The LOAD command (LOA) indicates that a device handler is to be made 


resident in memory and ready for service. I/0 requests to a device 
are not honored unless the requested device handler is resident. 


FORMAT 
LOA [D] handler-name[:] 
where 


handler-name is the task name of the handler to be loaded. 


EXAMPLE 


MCR>LOAD LP 


The line printer device handler is loaded into memory. I/O 
requests to the LUN assigned to the line printer can now be 
honored. 
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‘D.8 MOUNT COMMAND (MOU) 


FUNCTION 


The MOUNT command (MOU) allows the user to make a 
available to the system. MOU creates the Volume Contro 
and declares that the volume is logically on-line fo 
File Control Primitives. 


FORMAT 
The format listed below is the general format for the 
MOUNT for multivolume magnetic tape is somewhat diffe 


and is discussed in section D.4.1. 


MOU[NT] dev: volumelabel[keyword(s) ] 


where: 

dev: is the device specification for the 
contains the volume being mounted. 

volumelabel 
is the volume label of the volume bein 
label specified is compared to the label 
volume’s home block, to ensure that 
mounted volume is the one to be logicall 
visible) by the system. 

/keyword(s) 


are optional modifiers that allow the 
to override volume characteristics that 
to the volume when it was initialized. 
keyword options are provided. 


NOTE Notations listed to the left of 
keyword options equate to the following: 


* Applies to disk and DECtape only 


Overrides the corresponding option 
INITVOL 


+ Applies to magnetic tape only 
/CHA=[characteristic word] 


This option changes the device 
word. Possible parameters for this 


MOU 


selected volume 
1 Block  (VCB) 
r access by the 


MOUNT command. 
rent in format, 


device that 


g mounted. The 
field of the 
the physically 

y mounted (made 


privileged user 
were assigned 
The following 


specified at 


characteristic 
option are: 
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K+ FOR -a 


non-Files-1l 
(FOREIGN). 
specified 


assumed. 


ATCH -device 
exclusive use by one task. 


DCF 


When 
DCF is 
may be 


removes restrictions. 


NOTE 

ATCH and DCF are legal for 
only when it is mounted as 
Example 

/CHA= [FOR,ATCH] 
* /UNL 
This option specifies that 
to be left unlocked, thus 
the index file 
+ /DENS=magnetic tape density 
Possible parameters are: 
800 for 8808 BPI 
1608 for 1609 BPI 
Example 
/DENS=800 


/ACP=task name 


magnetic tape 
FOREIGN. 


the volume’s index 


structured 


volume 


attached 


file 


this parameter is 
automatically 


for 


-device control FUNCTIONS permitted; 


is 


giving tasks write access to 


This option allows the user to designate the task 


is to be in the file processor for the volume. 


Example 


/ACP=DSKFI 


Example 


/EXT=5 


This 


/EXT=default file extend increment in blocks 


/FPRO=[default file protection] 


that 


option allows the user to change the default file 


protection assigned to new files created on the volume. 
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Each entry consists of from one to four letters which 
have the following meanings. 
R - for READ access 
W - for WRITE access 
E - for EXTEND access 
D - for DELETE access 


The absence of one of these letters in an entry 
signifies the access right is denied to the user. 


Protection code subparameters (system, owner, group, 
world) are positional; therefore, the location of an 
entry in the parameter string defines the user to whom 
the codes apply. 

Example 


/FPRO= [RWED,RWED,RW,RW] 


In this example, group and world are denied extend and 
delete access. 


/LURU=number of directories to keep pre-accessed 
Example 
/LRU=3 
/OVR 
This switch allows the user to override the volume 
label check. 


/OVRFSID 


This option is used to override the set identifier 
check. This option is reguired when processing 
magnetic tape with inconsistent file set identifiers. 


/OVREXP 
This option is used to override the expiration date 
check. Allows the user to overwrite un-expired 
magnetic tape files. 

/PRO=[system, owner, group, world] 
This option allows the user to change the volume access 
privileges. Each entry consists of from one to four 
letters which have the following meanings. 
R - for READ access 
W - for WRITE access 
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E - for EXTEND access 
D - for DELETE access 


The absence of one of these letters in an entry 
Signifies that the access right is denied to the user. 


Protection code subparameters (system, owner, group, 
world) are poSitional; therefore, the location of an 
entry in the parameter string defines the user to whom 
the codes apply. 
Example 

/PRO= [RWED,RWED,RW,RW] 


In this example, group and world are denied extend and 
delete access. 


/UIC=[uic] 
This option specifies the volume UIC to be 
used for the duration that the volume is 
mounted. 


Example 


/UIC=[11,11] 


D.-8.1 Format For Mounting Multivolume Magnetic Tape 


The following format should be used to mount multivolume magnetic 


tape. 


MOU[NT] MT(nl[n2,...,nn]):(labell[,label2,...,labeln] 


wheres 


n 


label 


[/keyword(s) ] 


is the logical tape drive number(s) (in the order of 
selection) representing the drive(s) to be dedicated to 
the processing of the multivolume set. If only one 
drive is being dedicated, the parentheses may be 
omitted. 


is the volume label(s) (in order) that constitute the 
volume-set. Only the volume label for the first volume 
in the set need be specified. If further labels are 
specified, they will be used by the file processor’ to 
validate further volumes as they are requested. If no 
Further labels are specified, it is up to the user to 
ensure that the correct volume is placed on the 
appropriate drive when requested. 


NOTE 


A separate unit number need not be 
specified for each volume in the set. 
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The file processor processes volumes 
sequentially down the list of specified 
units, until the last unit is’ reached. 
If more volumes are to be processed, a 
mount request, for the next sequential 
volume to be mounted is issued for one 
of the units listed. 


/keyword(s) 


See keywords provided for the general class of MOUNT 
command. 


TECHNICAL NOTES 


Because of the large number of options available with the MOU command, 
it may not be possible to enter the entire command string on a_ single 
line. For this reason, MOU can accept multiline commands. To 
accomplish this, the user must follow the procedure outlined below. 


1. Initiate MOU as follows: 
MCR>MOU 


When MOU is ready to accept command lines, it issues the 
following prompt: 


MOU> CR 


2. At this point, multiple lines can be typed in to MOU. Each 
line except the last must contain a hyphen (-) as the last 
character entered. When MOU recognizes the hyphen, it 
assumes that the command line is incomplete, and reissues the 
MOU> prompt for more parameters. When the last line is 
entered (no hyphen), MOU begins processing the command. See 
example number 3. 


EXAMPLES 
1. MCR>MOU[NT] DK1:S5YS094 


In this example, a request is made to mount disk volume 
SYS@04 on DKl:. None of the volume’s attributes are to be 
overridden. 


2. MCR>MOU MT(1,2): (RICK,SHEILA, LAURA,JEN) 


In this example, a request is made to mount multivolume 
magnetic tape. Logical tape units 1 and 2 are reserved for 
processing. At the time the mount request is being 
processed, tape volume RICK must be physically mounted on 
logical tape unit 1; otherwise, the label check will fail. 
No label check is made for tape unit 2 until the file 
processor is ready to process the next volume (SHEILA). 


PAR 
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D.9 PARTITIONS COMMAND (PAR) 


FUNCTION 


The PARTITIONS command (PAR) lists a description of each memory 
partition in the system. 


FORMAT 
PAR[TITIONS] 
EXAMPLE 
MCR>PAR 
SYDISK 871490 803490 UC 
SYS 975000 915000 SC 
GEN 112000 6290009 TC 
TTY 732000 011100 UC 
NOTE 
"UC" means "user-controlled" partition; 
Be” means "system-controlled" 
partition; "TC" means "timesharing". 


TECHNICAL NOTES 


1. 


The PARTITIONS command lists the: 


a. Partition Name 
Ds Partition Base (octal address) 
Cx Partition Size (octal) 


ean Control Code UC, SC or TC. 


The PARTITIONS command can be used to check that all 


available memory has been allocated. The highest memory 
address allocated can be determined by adding the Base and 
Size of the last partition in the list. In the example 


above, the highest memory address for the TTY partition would 
be 7320008 + 911198 which equals 743100. Therefore, 743100 is 
the highest address used. Memory higher than that address 
should be allocated by increasing the size of a partition 
(normally GEN). If the system had 124K (7690089 octal bytes), 
then 14709 (that is, 7600800-743100) bytes will not be 
allocated. Therefore, one partition should be increased by 
14788 bytes to use all available memory. 
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D.19 REDIRECT COMMAND (RED) 


FUNCTION 
The REDIRECT command (RED) allows the operator to redirect all I/O 
requests made for a pseudo device to the physical device unit with 


which it is associated or allows a spooled device to be redirected to 
another spooled device of the same type. 


FORMAT 


RED[IRECT] new-dev:=old-dev: 


where 
new-dev is the new device unit symbol, followed by an 
optional unit number (zero is assumed). 
= is notation signifying the dredirect action. 
old-dev is the old device unit symbol, followed by an 
optional unit number (zero is assumed). 
EXAMPLES 


1. MCR>REDIRECT LP@:=CL: 


Redirect all I/O requests for CL to device TT3; where both 
the devices are set output spooled 


2. MCR>RED LP1:=LPQ: 


Redirect all I/O requests from device LP@ to device LPl. 


TECHNICAL NOTES 


1. The RED command does not redirect any I/O already in the 
queue. Previous I/O requests are not transferred. 


2. If, through a sequence of Redirect commands, the user 
establishes a redirect chain which returns to old-dev, the 
following message is issued, and the RED command is rejected: 


RED -- CIRCULAR REDIRECT CHAIN 


SAV 


D.11 SAVE COMMAND (SAVE) 


FUNCTION 


The 


FORMAT 
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WARNING 


The SAVE command should be executed only 
when no tasks are running. 


SAVE command is 


SAV[E] [/switch] 


used to record the core image of an IAS 
system on the disk from which it was originally bootstrapped, so 
that a bootstrap can reload it and start up the system. 


is the following optional switch: 


/MOU=dev: [dev:...:dev] 


This switch is used to allow the system 
saved with the specified devices mounted. 
Technical Note 3. 


NOTE 


system still has volumes 


mounted on it and the /MOU- switch 


SAVE command has not been 


specified, the save will not occur. 


the current status of the system is 


on the disk from which it was originally bootstrapped. 


where: 
/switch 
If a 
to the 
EXAMPLE 
A ae MCR>SAVE 
In this example, 
2% MCR>SAVE /MOU:DFQO: 


In this example, the system is saved with DF@: mounted. 


TECHNICAL NOTES 


Lee 


to be 
See 


saved 


The SAVE command should be requested only when the system is 
inactive. This command is intended to provide the user with 
development stages rather than crash recoveries. 
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The SAVE command will attempt to record (on the_= system 
device) all memory specified at system generation time. If 
more memory exists than was declared at system generation, 
only the declared memory will be saved. If, however, less 
memory exists than was declared at system generation, SAVE 
will loop and not complete its operation successfully. 


SAVE will not permit the system to be saved with volumes 
mounted. When specifying the /MOU switch, the user must 
consider the following information about Files-1ll volumes: 


a. When a volume is mounted, volume control data is 
established in memory to reflect the volume’s’ current 
file status. This data is updated with every file 
operation, 


be When a volume is dismounted, the volume’s control data 
is reset. 


Cx If the uSer selects to save the system with volumes 
mounted the volume control data for each mounted volume 
is saved, reflecting the current status of the volume. 
It is imperative that no file activity occurs on_ the 
volume between the time the system was saved, and the 
next bootstrapping of the system. Otherwise, the 
integrity of the volume will be destroyed. 


d. When the system is re-bootstrapped, the status of the 
volume must be exactly the same as it was when the 
system was saved, or the integrity of the volume will be 
destroyed on the very first file operation. 


NOTE 


After the system is re-bootstrapped, and 
before any file activity has occurred, 


the uSer can execute the following 
commands to ensure the integrity of any 
volume: 


MCR>DMO devs: 
MCR>MOU devs: 
This will reset the volume’s' control 


data to reflect the current volume 
status. 


SET 
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SET command provides a facility for changing the MCR timeout, the 
terminal’s characteristics and for setting or clearing output spooling 


D.12 SET COMMAND (SET) 
FUNCTION 
The 
on a device. 
FORMAT 

SET [/keyword(s) ] 
where 


/keyword is 


one or more optional keywords which, when 


specified, alter or set the default values’ they 
represent. The following keyword options are 
provided: 


/UIC= 


/TMO= 


[group,member ] 
This option allows the user to change the 
default UIC to the one specified to the right 
of the equal sign (=). 
Example 

/UIC=[2869,2990] 


nnnnn 


This option allows the user to change the MCR 
timeout value. The number nnnnn is a decimal 
value (any number up to 32767) representing the 
numoer of seconds MCR is to wait for a command 
before timing out. 


Example 


/TMO=90 


/LA30S=dev: [dev:...:dev:] 


This option defines the specified device(s) as 
having LA3@S characteristics. 


Example 


/LA30S=TT1:TT2: 
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/LA30P=dev: [dev:...:dev: ] 


This option defines the specified devices as 
having LA3@P characteristics. 


Example 


/LA3OP=TT1 :TT2: 


/KSR3 3=dev: [dev:...:dev:] 


This option defines the specified device(s) as 
having KSR33 characteristics. 


/SP=dev:[dev:....:dev:] 


This option defines the specified device(s) as 
being available to the output despooler for the 
spooling of spooled output files. 

Example 


/SP=LP:TT1: 


/-SP=dev: [dev:...:dev:] 


This option defines the specified device(s) as 
no longer being available to the output 
despooler for the spooling of output files. 
Example 


/-~SP=TT1:TT2: 


MCR>SET /SP=LPQ: 


Sets the line printer LP@: as an output spooled device. 


MCR>SET /LA39S=TT1:TT2:/SP=TT3: 


In this example, the following actions are performed: 


ae 


b. 


TT1:, TT2:, and TT3: are defined as having LA3@S 
characteristics. 
TT3: is made available to the output despooler. for _ the 


spooling of output files. 
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D.13 TIME COMMAND (TIM) 


FUNCTION 


The TIME command (TIM) allows the operator to list the time and date, 
Or to alter the time and date values in the system clock calendar. 


FORMAT 
TIM[E] [time] [date] 

where 
time is specified in the format hh:mm:ss 


date is specified in the format dd-mm-yy 


NOTE 


If the TIME command is executed without 
parameters, the current system time and 
date will be listed. Also, if either or 
both of the parameters (time or date) 
are specified, the corresponding field 
in the system will be altered to the 
value specified by the parameter. 


EXAMPLE 


1. MCROTIM 9:10:28 26-JUN-75 


in this example the system time and date are changed to 
9:10:28 and 26-JUN-75 respectively. 
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D.14 UNFIX COMMAND (UNF) 


FUNCTION 


The UNFIX command (UNF) frees "fixed" tasks from memory. 


FORMAT 


UNF[IX] taskname[/TI=dev] [,taskname[/TI=dev],...] 


where 

taskname is the name of the task being unfixed. 

/TI=dev is an optional switch (appended to the taskname) 
which allows the uSer to unfix any task in the 
system by specifying its TI (dev is the device 
mnemonic for the terminal corresponding to the TI 
under which the task is to run). 

EXAMPLES 


1. MCR>UNFIX XKE 
Unfix task XKE, freeing it from memory. 
2. MCR>OUNFIX 2402, NK111 


Unfix task 2402 and task NKlll. 
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D.15 UNLOAD COMMAND (UNL) 


FUNCTION 


The UNLOAD command (UNL) causes the indicated device handler to exit, 
releasing its memory and cauSing the device to become inaccessible. 


FORMAT 


UNL[OAD] handler-name[:] 


EXAMPLE 
1. MCR>UNLOAD LP 


In the example above the request unloads the line printer 
handler task. 
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D.16 USER FILE DIRECTORY COMMAND (UFD) 


FUNCTION 
The User File Directory command (UFD) creates a user file directory 
(UFD) on the specified volume and enters its file name into the master 
file directory (MFD). The UFD command accepts the [group,owner] number 
as both the UFD name and the file owners’ UIC. 
FORMAT 

UFD device: [uic] [/switch] 


where: 


device: specifies the deivce that contains the volume to be 
acted upon. 
fuic] is the UIC of the UFD being created. 
NOTE 
The brackets which enclose the UIC are a 
required part of the parameter. 
/switch is one or more of the optional UFD switches 
described in Table D-3. 
EXAMPLE 


MCR>UFD DK1:[1,1]/ALLOC=190. 


In the example above, the command created the UFD on disk device 
DK1 with the UIC [1,1] as the directory name; space is allocated 
for 198 directory entries. 


MCR COMMANDS 


Table D-3 
UFD Switches 


Description 


This switch allows the owner of the directory to 
selectively permit access to his file. This Switch is 
specified in the following format: 


/PRO=[system,owner ,group, world] 


NOTE 


If the /PRO switch is specified, the default 
file protection for the volume is used. 


/ALLOC This switch allows the owner of the directory to 
pre-allocate space for a specified number of directory 
entries. This switch is specified in the following 
format: 


/ALLOC=number-of-entries 


NOTE 


The number specified is assumed to be octal; 
the number may be specified with a trailing 
decimal point to represent a decimal value. 
The default is 32 octal. 
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ERROR MESSAGES 


During system generation, errors detected cause a message to be 
printed on the console. Phase 1 messages are preceded by a SGNI1; 
phase 2 messages are preceded by SGN2. System generation produces 
three types of error messages. 


1. Diagnostic messages -- These messages are informative and do 
not result in termination of system generation. The user 
Should not force termination if a diagnostic message is 
printed. Diagnostic messages are prefixed as follows. 


SGn -- *DIAG* 


2. Diagnostic message dependent on console input -- These 
message are nonfatal if console intervention is possible. If 
input is from an indirect file, the error is declared fatal. 


3. Fatal error messages -- These errors are not recoverable. 
System generation terminates the current attempt to build the 
System. Fatal error messages are prefixed as follows. 


SGn -- *FATAL* 


Error messages in this appendix are divided into one section for phase 
1 messages and another for phase 2. messages. Within each section, 
messages are presented in alphabetic order. 


1. PHASE 1 ERROR MESSAGES 


If an error occurs during phase 1 and the message Output handler is 
not loaded, a number is printed on the console rather than the error 
message. In the following section, the number associated with each 
message is provided to the right of the message. 


CANNOT REQUEST ...INV 4g 


Failure of the REQUEST directive or corruption of the 
communication data sent by SGN1 to ...INV (the special 
version of INSTALL) has occurred. If the latter is 
true, remove and reinstall ...INV and then try 
rerunning phase l. 
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DUPLICATE NAME 


A device name, partition name, or shared region name 
has appeared more than once. 


ERROR IN READING TASK IMAGE 

An attempt to read a task has failed. 
ERROR IN SfD TABLE CONSTRUCTION 

SGN1 has failed internally. 
ERROR ON COMMAND INPUT 


A hardware failure has occurred on attempting to read 
command input 


FILE POSITION ERROR 
An internal system generation failure. 
I-O ERROR ON FILE filename 


I/O error has occurred on reading or writing the named 
file. 


ILLEGAL CHECKPOINT DEVICE 


The checkpoint device was not defined by a 
DEV=directive. 


ILLEGAL ERROR -- SEVERITY number 
SGN1 has failed internally. 


¢ ia 


ILLEGAL SY INPUT 


This message can be caused by any one of the following 
conditions. 


Undefined device (no DEV command associated with 
1G) 

Invalid mnemonic 

Device for which no bootstrap program exists (see 
Section 5.4) 


ILLEGAL MULTI-PARAMETER SETS 


Muliple parameter sets have occurred in a directive 
that permits only one parameter set. 


IMPROPER "@" FILE SPECIFICATION 


File syntax specification incorrect. 
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INSUFFICIENT PARAMETERS 


All the parameters required by the directive have not 
been submitted. 


INVALID ACP TASKNAME 
The specified name of the file primitve tasks for this 
device was not nnnACP; i.e., the last three characters 
are erroneous. 


INVALID DEVICE TYPE <type> 


Device type not recognizable. The device type is not 
defined internally in system generation. 


INVALID KEYWORD IDENTIFIER 
Keyword in a directive cannot be recognized. 
INVALID PARTITION NAME 


An attempt has been made to install a task in a 
nonexistent partition. 


INVALID TARGET DEVICE SPECIFICATION 


A syntax error was made in specifying the target device 
and filename. 


INVALID TASK NAME 
Bad data was found in the header of a task INV has 
installed. Possibly a task has become corrupted. 
Start phase 1 again. 

MARK TIME OR WAIT FOR DIRECTIVE FAILURE 


SGN1L failed to issue one of these directives 
successfully. 


NO DYNAMIC STORAGE AVAILABLE 
No more nodes are available. Indicates nested 
generations may be required. Thus, the user must 
generate successively larger systems until he reaches 
his target system. Alternatively, some running on or 
installed tasks should be removed; then try again. 
NON-EXISTENT "@" FILE SPECIFIED 
The indirect file specified cannot be found. 


NO SPACE FOR POOL 


SCOM size insufficient to provide for any pool. 


33 


39 


16 


28 


35 


34 


22 


19 


12 


ERROR MESSAGES 


NO TELETYPE HANDLER (TT....) INSTALLED 
After all the installs for phase 1 were processed, SGN1 
found that no task with the name TT.... was installed. 
Insert the directive to install TT.... in the phase 1 
command file. This message is a warning; the system 
is operable. 

NO TELETYPE ZERO DEFINED CI, CO, AND CL NOT REDIRECTED 
TTO was not assigned. CI, CO, and CL have no 
assignments and should be redirected when the target 
system is initiated. 

OPEN FAILURE ON FILE filename 


File cannot be opened. The failure has occurred in 
attempting to open EXEC.TSK, one of the bootstrap .TSK 
or .STB files, or the system image output file. 
Usually either the file does not exist, or no- room 
exists on the disk to create the output file. 

OPTION LINE SYNTAX ERROR 
A syntax error exists in an directive line. 

OUTPUT I-O ERROR ON FILE filename 
An I/O error has occurred when writing the save file. 


OVERLAP IN REAL ADDRESS SPACE 


The base specifications and size specifications result 
in a space allocation conflict. 


REAL MEMORY SIZE EXCEEDED 


After summing memory requests, those requests are found 
to exceed the amount specified by the PDP11 directive. 


STD ENTRY NOT FOUND FOR A TASK AFTER INSTALL 


INSTALL has failed to create an STD entry. INSTALL may 
issue a message in addition to the one issued by SGN1. 
Alternatively, INV may not have run to completion. 


SYMBOL NOT FOUND symbol 
A symbol needed by SGN1 cannot be found in the 
appropriate bootstrap .STB file. The file either has 
not been built or has been built incorrectly. 


SYSGEN PHASE 2 NOT INSTALLED 


After all phase 1 installs were processed, SGN1 
determined that SGN2 was not installed. 


a 
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SYSTEM DISK HANDLER NOT ALLOWED IN “T° CONTROLLED PARTITION 
The system disk handler has been installed into a 
timesharing controlled partition. It must be put into 
a User of System controlled partition. 

SYSTEM DISK HANDLER NOT INSTALLED 


No task with the name xy.... was installed. xy is the 
device specified in the SY directive, which was. valid. 
See Section 3.4.2.1. 


SYSTEM DISK NOT DEFINED, “SY° NOT REDIRECTED 
SY has not been defined explicitly. Therefore, SGN1 is 
attempting, by default, to redirect SY to DKO. 
However, no such device has been defined by a DEV 
directive; SY cannot be redirected. 


TASK ...-INV NOT IN SYSTEM 


SGNlL requires the task ...INV to Operate but the task 
cannot be found. 


TOO MANY PARAMETERS 


More than the allowable number of parameters have 
appeared in the directive. 


VIRTUAL ADDRESS SPACE OF SCOM OUT OF RANGE 
The size specified for SCOM makes the virtual starting 


address less than 16080008; Administrator must reduce 
the size of SCOM. The maximum size of SCOM is 12K. 
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2. PHASE 2 ERROR MESSAGES 
ASSIGN LUN ERROR 

SGN2 cannot assign a LUN to SY. 
CHECKPOINT FILE ALLOCATION ERROR 


There is not sufficient contiguous Space on the disk to 
the checkpoint file. 


ERROR ON LOGGING DEVICE 

Could not successfully log. 
TO ERROR 

I/O ERROR has occurred. 
MARK TIME ERROR 

SGN2 has attempted a MARK TIME and the reguest failed. 
OPEN ERROR ON SYSBLD.CMD 

SYSBLD.CMD could not be opened. 
OPTION LINE SYNTAX ERROR 

A syntax error exists in an SGN2 directive. 
READ ERROR ON COMMAND FILE 

Command file cannot be read. 


REQUEST ERROR 


allocate 


SGN2 has attempted to REQUEST a task and the request failed. 


WAITFOR ERROR 


A WAITFOR request has failed. 


\ (backslash), 3-3 
/ (slash), 3-3 


3-1, A-1 


[311,107] SGDATA.MAC, 1-4, 4-1, 


A-1 


Allocating memory, 3-7 


Backslash (\), 3-3 
BM792YB bootstrap, 
BM873YA bootstrap, 
BM873YB bootstrap, 
BOOT command, D-2 
Bootstrapping, 2-3 
distribution tape, 5-6 
hardware, 2-3, 5-1 


or uo 
I 
wm W Dd 


Checkpointing, 3-19 

CKPNT directive, 1-3, 3-19 

CLI (Command Language 
Interpreter), 4-2 

Clock ticks, 3-5 

Command files, 

see indirect command files, 

Command Language Interpreter 
(CLI), 4-2 

Common areas, 3-9 

CPU specification, 3-5 


Data structures, 4-1 
Defaults, system, 3-156 

* DELAY directive, 1-4, 3-2 
DEV directive, 1-3, 3-13 
Device, 


characteristics, 3-13, B-l, 


specifications, 3-13 


INDEX 


DISMOUNT command, D-6 

Distribution system, 1-1 
transferring, 5-l to 5-7 

DPAR directive, 1-3, 3-18 


Editing files, 2-1 


Error messages, E-] to E-6 
EXEC directive, 1-3, 3-8 
Executive, 1-3, 3-8 


IAS, 3-8 
timesharing, 1-4 


File primitives, 3-21 
Files, system, A-1l 
FIX-IN-MEMORY command, D-8 
Floating point option, 3-5 


Hardware bootstrapping, 2-3, 5-1 


IASBUF, 1-4, 4-1 
IASCOM, 1-4, 4-1 
Indirect command files, 1-2 
editing, 2-1 

phase 1, 6-1 

use of in Stage 2, 1-4 
INITIALIZE VOLUME command, D-9 
INS directive, 1-3, 3-29 
Installing system tasks, 3-29 


Libraries, 

ITASCOM and IASBUF, 1-4, 4-1 
LIST COMMON BLOCKS command, D-19 
LOAD command, D-2@ 


MCR commands, D-l to D-36 
Memory, 

allocation, 3-7 

size, 3-5 
MOUNT command D-21 
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MRI1DB bootstrap, 5-l 


Node pool usage, 2-1, 3-11 


PAR directive, 1-3, 3-12 
Parameter file, 
terminal handler, 3-1 
timesharing executive, 1-4, 4-1 
Parameters, 
scheduling, 4-3 
set-up, 4-2 
Swapping, 4-4 
terminal handler, 3-1 
timesharing executive, 1-4, 4-1 
Partitioning memory, 3-12 
PARTITIONS command, D-26 
PDP11 directive, 1-3, 3-5 
Phase 1 of Stage 1, 1-2 
bootstrapping, 2-4 
procedures, 6-2 to 
Phase 2 of Stage l, 
bootstrapping, 2-5 
directive (*DELAY), 3-22 
system disk, 3-17 
POOL directive, 1-3, 3-11] 
Pool requirements for SGN], 2-1 
Procedures, 
Stage 1, 6-1 to 6-11 
Stage 2, 7-1 to 7-2 
Processor configuration, 3-5 


6-8 
1-3 


Rebooting saved system, 2-7 
REDIRECT command, D-27 


SAVE command, )=28 
Saving generated system, 2-6 
SCOM directive, 1-3, 3-9 
SET command, D-398 
SGAS (Shareable Global Areas), 
1-4 
SGN1, 2-4 
bootstrapping, 2-4 
SGN2, 1-3 
bootstrapping, 2-5 
Shareable Global Areas (SGAS), 
1-4 
Slash (/), 3-3 
Stage l, 1-2 
procedures, 6-l1 to 6-11 
Stage 2, 1-4 
procedures, 7-1 to 7-2 
SY directive, 1-3, 3-17 
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SY:[11,17]SYSBLD.CMD, 1-4, 6-1, 
6-9 
Startup, 4-1 
System, 
common areas, 3-9 
defaults, 3-16 
definition, 3-1 to 3-22 
distributed, 1-l, 5-1 
to 5-7 
rebooting saved, 2-7 
saving, 2-6 
startup, 4-1 
transferring distributed, 5-1 
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target device, 1-3, 3-4, 6-2 
TARGET directive, 1-3, 3-4 
Terminal handler parameters, 
1-4, 3-1 
Terminals, 
on DH11 or DJ1l1l lines, C-1l to 
C-6 
timesharing, 4-2 
TIME command, D-32 
Timesharing Executive, 1-4, 4-1 
Transferring distributed system 
5-1 to 5-7 


UNFIX command, D-33 

UNLOAD command, D-34 

USER FILE DIRECTORY command, 
D-35 
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User with little programming experience 
Student programmer 
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Non-programmer interested in computer concepts and capabilities 


Name __ en Cé ATCON 
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Organization 
Street 
NY a ee eh Code 
or 
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